[11.2 Gnome] Where to set shortname=winnt mount option?

Where do I set the default mount options for automounted removable drives, like memory cards?

Right now the cards are being mounted with shortname=lower. That option causes my (vfat) memory card’s files to appear with lowercase letters, but I’m more used to have 8.3-style msdos filenames as uppercase, (unless specifically mixed case).

I’ve tried editing the setting in gconf, as well as editing /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi, nothing works. Mount keeps using shortname=lower, regardless of what settings I put in those 2 locations.

Searching the forums gave me those 2 locations above, and nothing too current.

thanks

^up … … …

As HAL is the one that does the mounting, looking somewhere in its files might give you a clue. many be searching for “shortname=lower” will help.

But I admit that HAL is not the not very easy to understand.

I tried looking into this file: /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi

It doesn’t have shortname=lower anywhere, in only has

<append key="volume.mount.valid_options" type="strlist">shortname=</append>

I changed it to:

<append key="volume.mount.valid_options" type="strlist">shortname=winnt</append>

restarted haldaemon, but mount still shows shortname=lower

I tried to manually run gnome-mount, and it did try to use the gconf setting, however, it said that shortname=winnt is not allowed for my uid. It worked when set to win95 though, which is close enough.

gnome-mount -vdb /dev/sdf1
gnome-mount 0.8
** (gnome-mount:10586): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_label_EOS_DIGITAL
** (gnome-mount:10586): DEBUG: read default option 'shortname=winnt' from gconf strlist key /system/storage/default_options/vfat/mount_options
** (gnome-mount:10586): DEBUG: read default option 'flush' from gconf strlist key /system/storage/default_options/vfat/mount_options
** (gnome-mount:10586): DEBUG: read default option 'utf8' from gconf strlist key /system/storage/default_options/vfat/mount_options
** (gnome-mount:10586): DEBUG: read default option 'uid=' from gconf strlist key /system/storage/default_options/vfat/mount_options
** (gnome-mount:10586): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_label_EOS_DIGITAL with mount_point='EOS_DIGITAL', fstype='', num_options=4
** (gnome-mount:10586): DEBUG:   option='shortname=winnt'
** (gnome-mount:10586): DEBUG:   option='flush'
** (gnome-mount:10586): DEBUG:   option='utf8'
** (gnome-mount:10586): DEBUG:   option='uid=1000'
** Message: Mount failed for /org/freedesktop/Hal/devices/volume_label_EOS_DIGITAL
org.freedesktop.Hal.Device.Volume.InvalidMountOption : The option 'shortname=winnt' is not allowed for uid=100

So I set it to ‘shortname=win95’ in gconf, and it worked. The setting is in the following key

/system/storage/default_options/vfat/mount_options

It seems like I spoke to soon. It’s only reading the gconf and mounting shortname=win95 when I manually run gnome-mount. However, if I plug in the card reader, it still mounts as shortname=lower.

Further testing seems to show that gnome-mount isn’t even involved with my situation, that’s why it’s not using the values in gconf.

I renamed /usr/bin/gnome-mount program to gnome-mount.orig, and put a bash script called gnome-mount in it’s place, to try to intercept the call to gnome-mount. Plugging the card-reader in doesn’t seem to call gnome-mount at all.

HAL seems only concerned with enumerating devices, and not involved with the actual mount. While the changes to the .fdi file do reflect in lshal, whatever is doing the actual mount seems to be ignoring the HAL “recommendations”

Gnome-mount doesn’t seem to be involved either. manually invoking gnome-mount does read the gconf setting. However, replacing the gnome-mount binary with a wrapper script demonstrates that it isn’t being called, hence, doesn’t use gconf settings.

How do I find out which processes are involved with the automounting?

I am not with you here. May be we use the same words for different things, or different words for the same things (the base for a lot of misunderstandings in this world :wink: )

What we are looking at here is NOT automounting. Automount is an extension to NFS. Like NFS started by Sun Microsystems years ago. It is about mounting NFS mounts only when needed. That is when a user accesses a file inside the mount, that mount is then done. after some time of none usage, an umount is done. The main configuration is in /etc/auto.master. I repeat, that is NOT what we are talking about here.

I do not know what you mean by “enumerating devices”. When a device shows up, the kernel gives it an unique number (MINOR) within the category (MAJOR) it belongs to. The kernel then signals the udev daemon and udevd then creates the device special files like /dev/sdf, /dev/sdf1, /dev/sr0 and the /dev/disk/by-… entries in /dev/ (whatever is needed).

HAL is signaled by udevd. HAL checks if there is an entry for the device in /etc/fstab. When yes, HAL sees this as prove that the device is not to be handled by HAL and does not do anything. When HAL decides that is has to mount, it creates a mount point. For this it creates a directory in /media. The name of this directory will be the volume label of the partition. When no volume lable is available it will use the class of the device (disk, cd, dvd) and when allready in use it will add numbers to this (disk-1) to make them unique (thus, today the mountpoint may be /media/disk and tomorrow, when allready another device is connnected earlier, it may be /dev/disk-1 for tthe same device). Hal then does the mount (and here lies our big question: WHERE DO THE FS PARANMETERS COME FROM?). The mount is not done by any component of your desktop for the simple reason that they do not run as root.

HAL communicates with the desktop to find out who must be the owner of the mount point. HAL signals back to the desktop that it mounted and the desktop can then inform the user (e.g. by pop-up window). One of the problems here is that Linux is a multi user system. Thus which one of the running desktop sessions is involved here?

The above to make the whole process a bit more transparent to you. I am not a Gnome user, thus I do not know how the Gnome desktop handles this together with HAL.

Yes, probably.

What we are looking at here is NOT automounting. Automount is an extension to NFS. Like NFS started by Sun Microsystems years ago. It is about mounting NFS mounts only when needed. That is when a user accesses a file inside the mount, that mount is then done. after some time of none usage, an umount is done. The main configuration is in /etc/auto.master. I repeat, that is NOT what we are talking about here.

Understood, I am not talking about NFS, just talking about automatically mounted usb devices. Specifically, a card reader with vfat filesystem.

I do not know what you mean by “enumerating devices”. When a device shows up, the kernel gives it an unique number (MINOR) within the category (MAJOR) it belongs to. The kernel then signals the udev daemon and udevd then creates the device special files like /dev/sdf, /dev/sdf1, /dev/sr0 and the /dev/disk/by-… entries in /dev/ (whatever is needed).

HAL is signaled by udevd. HAL checks if there is an entry for the device in /etc/fstab. When yes, HAL sees this as prove that the device is not to be handled by HAL and does not do anything. When HAL decides that is has to mount, it creates a mount point. For this it creates a directory in /media. The name of this directory will be the volume label of the partition. When no volume lable is available it will use the class of the device (disk, cd, dvd) and when allready in use it will add numbers to this (disk-1) to make them unique (thus, today the mountpoint may be /media/disk and tomorrow, when allready another device is connnected earlier, it may be /dev/disk-1 for tthe same device).

This clears things up for me a bit, thanks.

Hal then does the mount (and here lies our big question: WHERE DO THE FS PARANMETERS COME FROM?).

This is my main issue, if it’s HAL that does the mount, then how do I properly edit the configuration to use shortname=win95? Whatever I edit doesn’t seem to affect the operation of HAL in any significant way.

The mount is not done by any component of your desktop for the simple reason that they do not run as root.

What you’re saying is that gnome-mount could not be responsible for mounting, since it’s not run as root?

HAL communicates with the desktop to find out who must be the owner of the mount point. HAL signals back to the desktop that it mounted and the desktop can then inform the user (e.g. by pop-up window). One of the problems here is that Linux is a multi user system. Thus which one of the running desktop sessions is involved here?

The above to make the whole process a bit more transparent to you. I am not a Gnome user, thus I do not know how the Gnome desktop handles this together with HAL.

From what you said, it seems that the mount is desktop-agnostic, and would probably be mounted by the same daemon/program/process whether on KDE or Gnome. The question is which one? And where does that process store it’s settings.

What you’re saying is that gnome-mount could not be responsible for mounting, since it’s not run as root?

Yes, but gnome-mount can talk to a daemon running as root (using e.g. DBUS) and that will then do the mount. That daemon might be HAL.

From what you said, it seems that the mount is desktop-agnostic, and would probably be mounted by the same daemon/program/process whether on KDE or Gnome. The question is which one? And where does that process store it’s settings.

HAL does the mounting on behalf of the desktop. When you (and everybody else if you have more users) log out of the GUI and connect a device, HAL will not mount. You can check this by logging in from logical screen 1 (using Ctrl-Alt-F1), become root and use

mount

When you then log in into the GUI (using Ctrl-Alt-F7 to get to the login screen) and check back at screen 1 with *mount *again, you will see it is mounted now. This is what I experienced in a test this morning.

When you use “HAL mount paramaters” in Google you will get some interesting results. Among them Arch Linux Forums / How to change hal mount options. At post #5 there is an example how to influence HAL’s actions. Not everybodies piece of cake.

I really appreciate your help Henk, and I don’t mean to sound ungrateful, because I’m really grateful for your help. However, I’ve been googling this since before christmas, and there seems to be only 2 solutions to my problem, neither of which work for me. And I don’t know the reason why it shouldn’t

I already created a 95-vfatcase.fdi file previously, I’ve tried putting it in /usr/share/hal/fdi/policy/10osvendor, as well as /etc/hal/fdi/policy/20thirdparty:

<?xml version="1.0" encoding="utf-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <match key="volume.fsversion" string="FAT12">
          <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">false</merge>
          <merge key="volume.policy.mount_option.shortname=win95" type="bool">true</merge>
        </match>
        <match key="volume.fsversion" string="FAT16">
          <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">false</merge>
          <merge key="volume.policy.mount_option.shortname=win95" type="bool">true</merge>
        </match>
        <match key="volume.fsversion" string="FAT32">
          <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">false</merge>
          <merge key="volume.policy.mount_option.shortname=win95" type="bool">true</merge>
        </match>
        <match key="volume.fstype" string="vfat">
          <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">false</merge>
          <merge key="volume.policy.mount_option.shortname=win95" type="bool">true</merge>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

In both locations, it doesn’t seem to have any effect. The key “volume.policy.mount_option.shortname” doesn’t appear in lshal. The only way I have succeeded in influencing the lshal output is by editing 20-storage-methods.fdi in /usr/share/hal…/10osvendor. And even if it did reflect the change in lshal, it still did not change the actual mount option used.

My suspicions:

  • Could it be that the values are being cached somewhere else, such that even restarting hald still uses the old values?

  • permissions problem on the .fdi file?

  • Something wrong with my .fdi file, that it doesn’t match the device?

  • mount options are controlled from another location I haven’t found yet?

  • mount options are hard-coded?

Sorry for leading you in circles. As you may have seen I am not a fan of HAL, mainly because configuring like this is a nightmare. I did configure things to udev and that is very easy compared to this.

I will give my opinion on your five questions for what it is worth:

  • caching could be, but I would think stop/start hald should empty it, in any case a reboot must do that.

  • when the permissions are the same as on the original files there can not be any problem. Owner: root, group: root, readable by all, directories searchable by all, writetable by root only.

  • hm, do not know.

  • there are some things hard-coded in HAL, like the */media *root for its mounts. It might be the case.

No, you’re not leading me in circles, in fact it’s a bit clearer to me now. Still, clearer doesn’t really help if HAL or whatever ignores my options.

thanks

I’ve spent last night mv’ing gnome-mount, halmount.py, gvfs-mount to another name. Hopefully to pin down which program is actually in charge of mounting. The theory is, if mount fails because the program is missing, then it was in charge of mounting.

However, it was not so fruitful, in all 3 cases, mount succeeded, indicating that none of those 3 were used (?). I still have to try mv’ing /bin/mount …

Moving /bin/mount is not usefull I think. It is about the parameters mount is called with, not about mount itself. Also be carefull not mv mount away over a boot, because then nithing can be mounted at boot >:(

mv’ing stuff around isn’t helping me fix the shortname thing. It’s supposed to pin down which program is actually mounting the disk. If I figure out which program is performing the actual mount, then maybe I’ll know how to configure it.

mv’ing stuff around doesn’t seem to affect the mounting in any way, mounts proceed as usual. Mounting is probably done by magic.

So I’m still stuck without a clue as to why changing HAL’s files doesn’t affect anything whatsoever. Moving binaries around doesn’t affect anything. And everything else I do is not fixing what should be a simple configuration, despite what the internet says.

I am still of the opinion that HAL does the mount. I do not know if it calls the mount utility for this or if it interfaces directly to the kernel. What you could do, while you are testing that thouroughly, it stopping HAL, and see what happens when you connect the device (nothing I think, but that is what you are testing :wink:

When you do not konw how to stop/start HAL, use YaST > System > Systemservices (Runlevel), look for haldeamon in the list and the rest is obvious.

I never thought of stopping HAL until you mentioned it. Surprisingly, after stopping HAL, the mount still occurs, and still mounts with shortname=lower! Told you it was magic :wink:

Well that’s really weird, shows that what we thought we knew, wasn’t really the case. Now I don’t know what’s really going on…

I am baffled, can not say any usfull thing atm. :’(

I have to help my wife in the garden now, but I do have something to think about in the meantime.

Haha, I have to go help my wife too. I’ll probably come back to this again tomorrow. In the meantime, I’ve been doing more googling and it seems HAL is being replaced in favor of DeviceKit.

Still have more reading to do.