[SOLVED] fstab vs udisks for mounting internal drives

securetodeath · 2018-10-21 13:45:32

Hi everyone,

I'm trying to understand what are the considerations for mounting partitions in internal drive via /etc/fstab vs udisks.

I've read the whole Arch wiki pages on both fstab and udisks and googled for an answer but couldn't find anything that covers my use case.
I realize that using fstab will make systemd mount the partition at boot time before a user logs in. Therefore, in case there are multiple users in the system who need access to this partition, this seems like the better option.
It is also my understanding that using udisks is better for removable devices like USB drives that may need to be mounted dynamically after the system already boots (though I guess one could also use udev for this?).

In my case, I'm the only user of my machine and the drives are internal, so it's not clear to me what do I need to think about when considering fstab vs udisks. My tendency is to use fstab since it seems simpler and less dependent on high level abstractions like dbus.

Can someone please help me understand this?

And more generally, can someone please explain to me the motivation for udisks? I assume it's about the dbus interface, but I'm not sure what exactly it provides that lower level system APIs couldn't easily provide to programs.

Last edited by securetodeath (2018-10-23 04:03:26)

Lone_Wolf · 2018-10-21 14:11:19

fstab or udisks for internal drives comes down to one question :

who should control mounting of internal drives ?
1. local admin
2. policy based algortihms (udisks relies on polkit / logind )

If your answer is 1, use fstab.

-------------------------------------------

Why does udisks exist at all ?

linux is setup to only allow root to mount devices that are not listed in fstab.
Over time there have been multiple approaches to allow users to mount such devices.
udisks is a recent addition and is required by KDE solid and Gnome gvfs.

Autofs is another approach, some filemanagers also offer mount/automount functionality for users.

Trilby · 2018-10-21 14:40:09

securetodeath wrote:

My tendency is to use fstab since it seems simpler and less dependent on high level abstractions like dbus.

That'd be mine as well.

securetodeath wrote:

can someone please explain to me the motivation for udisks? ... I'm not sure what exactly it provides that lower level system APIs couldn't easily provide to programs.

On the second part: neither am I. I don't use it. For the first part, people's tastes differ. I suspect any real answer to that question would sound very similar to someone explaining the motiviation for display managers and big DEs: some people like all those high level abstractions.

I suspect, given the way you are phrasing these questions, you should probably use fstab.

Last edited by Trilby (2018-10-21 14:41:05)

securetodeath · 2018-10-21 18:32:51

Thanks for your answers! Sounds like I use fstab.
Followup question: what directories are reasonable to use as mount points in my case?

Initially I thought /mnt/<label> or /media/<label> are reasonable, but I'm not sure after reading the Filesystem Hierarchy Standard version 3 (draft from 2015).

Specifically this doc states that /media is for mounting removable media and /mnt is for a temporary filesystem.
Another candidate is /run/media/<username>/<label>, but it feels strange to put a user specific directory in fstab.

Do you have any insights or recommendations about this?

Thanks!

Alad · 2018-10-22 11:10:21

linux is setup to only allow root to mount devices that are not listed in fstab.

File systems such as FAT have the user/users mount option, which allows to mount devices as a regular user with certain permissions. This is possible since /bin/mount is a suid binary.

So yes, using removable devices with fstab is perfectly viable. For internal devices there's no discussion - just use fstab.

Do you have any insights or recommendations about this?

Use whatever you like. The main difference is that /run is volatile, so removed on the next boot.

securetodeath · 2018-10-22 13:44:30

Thanks for your reponse Alad!

Alad wrote:

Use whatever you like. The main difference is that /run is volatile, so removed on the next boot.

But does that have any practical implication?
It's my understanding that /run will be rebuilt and my partition mounted early in the boot process, and since the storage in the partition is persistent, I don't see any significance in that aspect.
Or am I missing something?

loqs · 2018-10-22 14:47:59

securetodeath wrote:

Thanks for your reponse Alad!
Alad wrote:
Use whatever you like. The main difference is that /run is volatile, so removed on the next boot.
But does that have any practical implication?
It's my understanding that /run will be rebuilt and my partition mounted early in the boot process, and since the storage in the partition is persistent, I don't see any significance in that aspect.
Or am I missing something?

/run will be present but what will create /run/media/<username>/<label> ?

Slithery · 2018-10-22 14:57:54

Sod the FHS. I've always just used directories under /mnt

Trilby · 2018-10-22 14:58:58

To elaborate on the above, you could mount your device directly on /mnt, but this would not be a very good idea as nothing else could (easily/cleanly) be mounted under /mnt. Generally one would create a sub directory, e.g. /mnt/movies and mount the device there, that way when you add another device, you could add another subdirecory (e.g., /mnt/documents). If you create the mountpoint /mnt/movies once it will still be there ready to be used on the next boot.

In contrast, if you (try to) create /run/movies and mount the device there, it will fail on the next boot as the mount point needs to be recreated before the fstab entry can be processed. Also, if you try to mount directly to /run, you will cause a world of problems (just don't do that).

So for a relatively persistent internal device, mounting under /run via fstab doesn't seem wise to me.

Slithery wrote:

Sod the FHS. I've always just used directories under /mnt

I'd second that. I am generally an advocate for working toward compliance with reasonable standards whenever practical - however both criteria of reasonable and practical may fail to be met here.

Last edited by Trilby (2018-10-22 15:17:54)

ewaller · 2018-10-22 15:28:01

Trilby wrote:

... however both criteria of reasonable and practical may fail to be met here.

I agree. But mostly because what used to be reasonable and practical have been overcome by events. The FHS harkens to an era when 10Mb drives were large, so the file system was broken into little volumes that could hold all of a certain class of files. Some things you needed at boot, others you needed to administer the system, others were not needed until general users started logging in. It was reasonable when disks were measured in Mb. It was certainly practical. Now it is just cargo cult engineering.

securetodeath · 2018-10-22 15:50:15

loqs and Tribly: it actually does work to mount on /run/media/<username>/<label> in fstab from a test I just did.

ewaller: is the cargo cult you're referring to pertains to FHS stuff discussed on this thread, or do you mean more generally?

loqs · 2018-10-22 15:53:35

securetodeath wrote:

loqs and Tribly: it actually does work to mount on /run/media/<username>/<label> in fstab from a test I just did.

It works when the path does not exist?

securetodeath · 2018-10-22 15:55:09

I created the directory to test the fstab mount, then rebooted, and after the reboot the filesystem was mounted.

ewaller · 2018-10-22 15:58:24

securetodeath wrote:

ewaller: is the cargo cult you're referring to pertains to FHS stuff discussed on this thread, or do you mean more generally?

More generally. I was off topic -- something I sometimes do as threads approach a logical conclusion. Bad habit.

loqs · 2018-10-22 16:52:21

I missed that the fstab will be parsed by system-fstab-generator which will create a dynamic .mount unit for it and from man 5 systemd.mount

       Where=
           Takes an absolute path of a directory for the mount point; in
           particular, the destination cannot be a symbolic link. If the mount
           point does not exist at the time of mounting, it is created. This
           string must be reflected in the unit filename. (See above.) This
           option is mandatory.

securetodeath · 2018-10-23 04:03:59

Thanks for digging that up loqs!

Arch Linux

#1 2018-10-21 13:45:32

[SOLVED] fstab vs udisks for mounting internal drives

#2 2018-10-21 14:11:19

Re: [SOLVED] fstab vs udisks for mounting internal drives

#3 2018-10-21 14:40:09

Re: [SOLVED] fstab vs udisks for mounting internal drives

#4 2018-10-21 18:32:51

Re: [SOLVED] fstab vs udisks for mounting internal drives

#5 2018-10-22 11:10:21

Re: [SOLVED] fstab vs udisks for mounting internal drives

#6 2018-10-22 13:44:30

Re: [SOLVED] fstab vs udisks for mounting internal drives

#7 2018-10-22 14:47:59

Re: [SOLVED] fstab vs udisks for mounting internal drives

#8 2018-10-22 14:57:54

Re: [SOLVED] fstab vs udisks for mounting internal drives

#9 2018-10-22 14:58:58

Re: [SOLVED] fstab vs udisks for mounting internal drives

#10 2018-10-22 15:28:01

Re: [SOLVED] fstab vs udisks for mounting internal drives

#11 2018-10-22 15:50:15

Re: [SOLVED] fstab vs udisks for mounting internal drives

#12 2018-10-22 15:53:35

Re: [SOLVED] fstab vs udisks for mounting internal drives

#13 2018-10-22 15:55:09

Re: [SOLVED] fstab vs udisks for mounting internal drives

#14 2018-10-22 15:58:24

Re: [SOLVED] fstab vs udisks for mounting internal drives

#15 2018-10-22 16:52:21

Re: [SOLVED] fstab vs udisks for mounting internal drives

#16 2018-10-23 04:03:59

Re: [SOLVED] fstab vs udisks for mounting internal drives

Board footer