Best way to automount ext4 SSD

Those*

Thank you i used the unit example and it seems to work. One more question though. You used the /data/ example. I donā€™t seem to have that folder on root (always used mnt before). Do i have to create that folder manually?

Yes, you have to create the directory first.

You can choose any name you like, data was the example. You could use mygames, games, or any other (valid) name.

1 Like

IIRC only the leading directories need to exist when using units, the last part where it is mounted will be automatically created if non-existing yet.

  • systemd.mount.html#Where=

    If the mount point does not exist at the time of mounting, it is created as either a directory or a file.

    :information_source: It is not needed to use this keyword at all, it is implied by the unit name, which makes your unit easier to rename and change mount point at same timeā€¦

1 Like

Interesting. Btw can you actually use the same options youā€™d use with fstab? For example filesystem checks (sixth field in fstab) ?

No those fields are fstab dialect only, systemd uses other mechanisms.

To make a mount unit run a fsck first, you need to tell it so :wink:

  • Example using Filesystem LABEL:
    [Unit]
    ....
    # Do a fsck on the partition
    Requires=systemd-fsck@dev-disk-by\x2dlabel-xxxxxxxx.service
    After=systemd-fsck@dev-disk-by\x2dlabel-xxxxxxxx.service
    ...
    
    • See: man systemd-fsck@.service and variants.

@omano im still ignoring your personal attacksā€¦

1 Like

No - when you activate the unit it creates the full path to the mountpoint

But you need to set ownership - it is the best way on a single user system

Thank you again!. Just one more question :smiley: When creating such a mount file for a NTFS drive is there a way to specify which driver for (example ntfs-3g) is used?

Not that iā€™m aware of, just as you canā€™t do that with fstab :wink:
Only way is to have the driver installed that you actually use to mount NTFS partitions, and not the other :slight_smile:

Of course you can specify which driver should be used in fstab! Just use ntfs3 OR ntfs-3g.
I have no idea about the systemd syntax

1 Like

You definitely CAN do that with fstab, here it uses ntf3

UUID=2220FGJAF0AF98F5    /media/Windows10   ntfs3   defaults,noatime,ro,noauto 0 0
1 Like

@Teo , @Maracuja
Ok sorry then i completely misunderstood the question, or i wasnā€™t aware that NTFS drivers use different filesystem types to read the same format because i never use that filesystem. :woman_shrugging:

If the driver ntfs-3g uses ntfs3 as filesystem type, you should be able to use that same type in the mount unit alsoā€¦

[Mount]
...
Type=ntfs3
...

:vulcan_salute:

1 Like

No, its filesystem type is ntfs-3g.

For licensing reasons, the ntfs-3g driver runs in userspace, via the FUSE framework. The ntfs3 driver runs in the kernel itself and is intended to replace the old in-kernel ntfs driver.

Specifying either ntfs-3g or ntfs3 tells mount which driver to use.

I meant filesystem type in the context of fstab, hence in other words whatever you can use in fstab as filesystem type you should be able to use in a mount unit also (as shown above), because the fstab is translated by systemd it-self to mount units alsoā€¦
So unless they have a build-in table to change the type used in fstab ā†’ unit the two should be identical.

As last resort if one doubts what to use, you can always use the prehistoric fstab method, boot once and check the translated mount unit, and use that in your own mount unit (ofcourse you can use either one not both fstab and mount units for same mount else they will clash)

My 2 cents:

I use, and recommend systemd mount and automount units.

No, I donā€™t think theyā€™re neccessarily better than the older fstab way. My reasoning is as follows:

  • Theyā€™re much more verbose, so easier to understand. Especially for newcomers (which, AFAIK is who Manjaro targets);
  • Theyā€™re by default more fault tolerant. Iā€™ve had multiple times in the past where 1 mistake caused the computer to fail booting. Maybe this was beause of how I set it up in fstab, no nofail option, I donā€™t know and donā€™t really care anymore. This has never happened to me with systemd mount units;

Iā€™ve seen the argument that 1 line in fstab is quicker and easier than a systemd unit, and Iā€™ll grant you a line is quicker than a file. But itā€™s also much more condensed, which makes it much harder to understand, especially for newcomers.

Life goes on, goes forward, and we can either move along and adopt the good it brings us, or we can stick and stay behind and stagnate. But be careful when you stagnate, you might get so bitter and stuck in your ways that you donā€™t see progress and see any movement as a step backwards.

And that is why Linux will be seen as an exclusive club, sort of thing.

Quoting myself from a reply to someone else in PM :wink:

In contraryā€¦Just a small exampleā€¦

  1. Try to make sure some service has been started before your mount using fstabā€¦
  2. Try to mount conditionally, like kernel parameters used or not, environment variables set or not, virtualization used or not etcā€¦ using fstab
  3. ā€¦

Yeah. It does make things (much) easier, Iā€™ll grant you. It is very flexible. You donā€™t have to convince me.

The same can be done with 1 small systemd unit, that would have required a script normally, so yeah. Itā€™s better for 99% of use cases, I think. But that doesnā€™t mean it neccessarily better for someone specific.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.