I wholeheartedly agree that normal users shouldn't have to bother with such an arcane and technical thing as mount options. Especially for frequently used media such as digital cameras. I also agree that GNOME shouldn't make the corner cases impossible - it's fine to make them a bit harder and (in general) hide the options and knobs somewhere - making them impossible is not OK.

On the topic of mount options, the way GNOME currently works (e.g. GNOME 2.26 with devkit-disks support as in e.g. Fedora 11) is that if a device is referenced in /etc/fstab, then the mount operation will use that (mount(8) is run as the user) - if not, then (after authorization checks) we mount it with safe (e.g. nodev, nosuid) and some default mount options. This allows technical users to e.g. add

 /dev/sdXN   /   vfat   defaults,shortname=mixed,iocharset=iso-8859-1,utf8=0,user 1 1

to /etc/fstab to specify options for device /dev/sdX (X being the drive letter, N being the partition). To make this work in a hotplug world, just use the symlink in /dev/disk. For example, to specify a disk by one of it's unique ids, you can use e.g.

 /dev/disk/by-id/ata-ST3320620AS_9QF9X4G3-part1
 /dev/disk/by-uuid/22AA2C32AA2C053F
 /dev/disk/by-label/EOS_DIGITAL

or to specify by the connection path, you can use e.g.

 /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0-part1

So this already works and, FWIW, has worked since GNOME 2.8 (FC3 and RHEL4 for RH systems).

Whether we should add UI to allow you to specify mount options from within GNOME is an interesting question - my view is that it's not needed. See

 http://lists.freedesktop.org/archives/devkit-devel/2009-June/000225.html

for an analysis of the problem. So the conclusion here is that a set of good defaults will work out of the box, at least (on a properly configured system) it will not cause the user to see wrong filenames.

We already have bug 585423 open asking for a way to store per-mount options.  I'm going to make this bug depend on that one.

It would help if you could list what (useful) options you think should be accessible from the UI. Right now the only per-device options (which are actually not mount options per se) I can think of is the

 [*] Optimize for quick removal
 [ ] Optimize for performance

but I haven't thought a lot about whether these options even make sense on current Linux or at all (I'm leaning towards that they don't).

(Honestly, my guess is that we can't find any (useful) options for mounting filesystems on block devices so I will probably end up closing this bug - either way, the discussion here is useful in itself so we can point back to it / reopen the bug it if things change.)

Any mount option presented in the UI would have to be understandable by random people. And I've not ever had mount options that do that.

Even in your example, I don't understand what "quick removal" vs "performance" gives me, and certainly I don't get which of those I should chose. I'm more reminded of http://www.joelonsoftware.com/uibook/pictures/Stupidest_Dialog_Ever.gif (which kinda has the same options even)

David, thank you for your kindly reply! Would you mind keeping this "bug" open for a few more days, such that I will have some time to think over what you have suggested and give you more feedbacks on this topic. I have a sense that this is not about technology, instead, it is about user habit, the way of using desktop environment. Thanks!

I have read over most comments regarding mount options, and here are some of my thoughts and suggestions.

First of all, the ultimate goal of our discussion and Gnome design is to make the use of external storage media as easy as possible, no matter who does the job of setting appropriate mount options: computer gurus, innocent users, or the GUI environment.

I fully agree that we should let the GUI to do most work and set up everything correctly and automatically if it's possible to do so. As David mentioned in his post in June, there are many different cases where empirically reasonable guesses are needed in order to make the GUI smart. Let's take VFAT as an example. I am a pragmatical and regular user, not computer expert, so I just want everything to *work* as expected. Before Fedora 11, I always set the mount options for VFAT as: shortname=winnt and utf8. Then everything works as it is: file names keep the same all the time and non-alphabetic characters (even Asian two-byte characters) are correctly displayed for any kinds of file transfer between Fedora Linux and Windows XP. The synchronization command rsync works correctly. Of course, if name encoding is not utf8, it is usually difficult to make a correct guess, as you pointed out. On the other hand, shortname=winnt is working always. As I noticed in recent release of KDE 4.2.x, it quietly passes shortname=mixed as a default mount option to VFAT partition meanwhile it has not implement the functionality of specifying per-mount options yet. However such effort has solved my problem of synchronization of my data files from my computer to my portable hard drive which uses VFAT for interoperation with Windows computer conveniently.

However there exist many situations where the GUI cannot figure out correct mount options. In these cases, users should be allowed to specify mount options explicitly somewhere. These mount options are certainly not "quick removal" versus "performance" types of choices, because such "options" are only for regular users so that the GUI still needs to figure out the *actual* mount options to use. As David pointed out, /etc/fstab is a place where users can put some global and static mount options. There are a few minor inconvenience here: the partitions specified here cannot be mounted automatically when removable storage media is plugged in, and second the permission mode cannot set to current console user dynamically. For now, I can only mitigate such inconvenience by assigning users to the "disk" group, use "uid=0,gid=6," to allow uniform access to the media, and then mount the partition in command line every time when removable media is plugged in. I guess there must be a better solution than what I currently have, so that the users without any expert knowledge are still able to use their USB disk or any other portable storage devices as convenient as they used to.

Technology can do great job when it can serve users' needs.

Best Regards

I just recalled a minimum requirement of the mount function of gvfs/DeviceKit module purely from GUI users' perspective:

Regardless of whose responsibility to set/change mount options, two requirements must be met:

* VFAT mount options must be set to a level empirically good enough, such that regular operations on VFAT by ordinary GUI users will produce expected results;

* The functionality of automatic mount of VFAT cannot be lost even when users manually set mount options no matter from GUI dialog boxes, in /etc/fstab, or anywhere;

A little explanation for above two points:

The first point deals with the situations where it's impossible for Gnome to make a correct guess of what language encoding that users may use for some type of media partitions, it is reasonable enough for Gnome: (1) to assume UTF-8 for these partitions, and then (2) to let users to specify language encoding explicitly. From users' perspective, such default behavior of GUI makes lots of sense, no matter for OS-free type of ordinary people, or for computer geeks.

The second point mainly serves the ultimate purpose of Gnome GUI: an intelligent agent that can deals with tedious and laborious manual work for computer users. A well designed GUI not only makes its users' life simple and convenient, but also makes up good reputation and increases its user base.

In a summary, I know it may be "too much" to put such a standard of industry design on the development work of free desktop environments. However the gain from seeking perfectness is tremendous and unlimited.

Thanks!

If I may put my two cents in, the UI for mount options is not needed, but there definitely should be a config.

It seems that there can't be any universal default options for VFAT suitable for everyone. And fstab is not enough to override them, as it applicable to predefined disks only. For example, I need "shortname=winnt", "fmask=0113", and "quiet" (for midnight-cmd) options for _any_ USB stick and SD-CARD.

I think gconf settings would be enough for fine-tuning the options. And there were well known settings in gconf:system/storage/default_options, but they are not used anymore. Why is it? I hope nobody would object if it will be re-implemented. It seems it should not be too hard.

Best wishes!

I'm facing a problem: the current policy for mounting USB drives is to mount as root and using options rw,nosuid,nodev,uhelper=devkit. With these options, I cannot write anything to my hotpluggable USB disks using ext3/4 as a user.

In order to make it writable, it means either to have an /etc/fstab entry for all hotpluggable devices on all machines or use every time the console (chown user.user /media/181...). Both ways are not "it just works" because I need to use the command line very frequently.

An option in gconf would be really great in this situation.

There are manifold scenarios and a lot of substantial, filesystem specific mount options. A performant GUI should reflect that and allow users to pass their knowledge ad hoc to the system.

I'd like to add my two cents to Andrew Novikov's.  I used the gconf variables to set default mount options, and I'd like to see support for that put back into gvfs.

I find the /etc/fstab workaround to be insufficient for a number of reasons.  In particular, I use a lot of different card readers and cards, and having to list them all in /etc/fstab is going to be a maintenance nightmare.  I just want vfat mounted the way I want, regardless of how it appears to the system.

If I had some assurance that this functionality wouldn't be turned down, I might even write up a patch.  It's pretty clear where in ggduvolume.c to make the change, and there's already a well-known gconf value to reference.

Thanks!

Another two cents on this from me:

We are using GNOME in a corporate environment and need to mount all removable media (i.e. those *not* explicitly mentioned in /etc/fstab) 'noexec'. We are currently doing this using said gconf options, and we definitely need a way to do so with DeviceKit also.

This is surely not something a 'normal' user would expect, but it is a good example that there can be no sensible defaults for everyone and every situation.

@Marc Horowitz
If you can write such a patch with little effort, I might be interested even if the gnome developers would turn it down. I am already maintaining a few "custom-patched" packages here, and we absolutely need this one.

Today VDI application are growing fast, and most of them relies on sharing files from the guest computer. If gnome doen't give the user an easy way to change permissions on USB mounts (i.e.: 644), no share will be available from VDI on the USB ports.

(In reply to comment #6)
> If I may put my two cents in, the UI for mount options is not needed, but there
> definitely should be a config.
> 
> It seems that there can't be any universal default options for VFAT suitable
> for everyone. And fstab is not enough to override them, as it applicable to
> predefined disks only. For example, I need "shortname=winnt", "fmask=0113", and
> "quiet" (for midnight-cmd) options for _any_ USB stick and SD-CARD.
> 
> I think gconf settings would be enough for fine-tuning the options. And there
> were well known settings in gconf:system/storage/default_options, but they are
> not used anymore. Why is it? I hope nobody would object if it will be
> re-implemented. It seems it should not be too hard.
> 
> Best wishes!

The above comment describes my feelings precisely.

I agree that there's no need for a present a UI with mount options, but SOME way to set non-fstab reliant, per-filesystem mount options is, for me at least, essential.

From the downstream bug:

It is hard-coded. That's bad.

Stripping whatever is hard-coded and reading it from a text file would be great.

How did Nautilus decide the mount options for a FAT or NTFS hot-plugged disk? Where is it written? If it's still some .c file then it should definitely be fixed.

I myself really do hate all the rsync/unison problems I get every time summer comes or every time I go to another country, so I would for instance add tz=UTC as a mount option for FAT32 to my configuration file. But if it is really that important that the users who created their files at 6:13 in their dual-boot operating system see it as 6:13 in Gnome, then maybe it's better not to have tz=UTC as default, and let rsync users do their manual change. But having to patch .c filees, apt-get build-dep etc etc etc etc, that is ugly.

PS: Hard-coding is almost similar to closed-source.

It's artificially forcing anyone who wishes to exert their Freedom to accomplish task that were not really needed to make the changes they want.

For instance, learning the particularities of a programming language, patching source files, recompiling, re-installing etc etc, that's not really need if all I want is to change the default values of umask and timezone.

Otherwise, one could compile source code, uncompile it in assembler, and say that it is Free Software. It isn't.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/100.