Devmon + udevil is mounting properly, but it is not unmounting. Udevil attempts to unmount a device in /dev that does not exist since it has allready been removed.

Not sure exactly what you mean. What is causing udevil to attempt to unmount?

FYI, udevil cannot unmount a device that has been removed. For one, it has no way to tell if the device is system internal once it's gone. Thus the proper way to use it is to unmount the device before removing it. This is also safer in terms of not corrupting the fs.

devmon by default unmounts removable drives on exit. If it attempts to unmount a missing device, again this is likely because the device was not unmounted before being removed.

Did some digging and it appears that the problem is that devmon is trying to mount the media twice. Here is the output produced from inserting a thumb drive:

That's an unusual device - usually a partitioned device won't show hasmedia for sdd, only for sdd1.

It looks like sdd1 was not mounted, or was it? Is /media/ARCH_201108-2 present and mounted after insert?

One thing about devmon - it will try to mount a device if there is any indication it might succeed (such as hasmedia), even if there is no apparent filesystem, because udev isn't always accurate. So it tries and fails. But in this case the mount error is odd. After insertion and devmon's automounting, try:

mount | grep /dev/sdd

and

cat /proc/partitions | grep sdd

to see what is actually happening. Also, what is the output when the unmounts fails? And how are you unmounting - by exiting devmon?

Also run this again after unmounting/removal:

mount | grep /dev/sdd

Note that devmon only unmounts devices on exit, unless you run it in client mode to unmount manually. If you're expecting something to be automatically unmounted on removal, you may need a udev rule for that. It's generally unsafe to remove before unmount.

EDIT: Also, mount's error that sdd1 is already mounted is odd - how did it get mounted? Make sure there are no other automounters running (eg thunar gvfs, udev rules, etc). Otherwise the behavior gets confusing.

In general, if devmon mounts both sdd and sdd1, then you need to unmount both before removal - they are two different filesystems.

I decided to try udevil and it seems to work for the most part. I do have a couple questions:

1. Are the instructions for mounting NTFS-3g valid for Arch Linux? Since ntfs-3g provides both mount.ntfs and mount.ntfs-3g, I suppose I would have to delete the former file before I can create the link. Also you might want a reminder on the website that for Arch Linux, mount.* is located under /usr/bin/ not /sbin/.

2. I have an external drive with two partitions (/dev/sdb1 and /dev/sdb2) and udevil mounts them fine. However before mounting the partitions, it also tries to mount the entire device too (/dev/sdb). It seems harmless (it just fails) but is there a way to tell it to stop doing that?

The old behavior with devmon + udisks was to unmount and delete the directory in media when the media was removed. It really is not all that "unsafe" and is how most people use their computer.

devmon has never done anything automatically on removal unless you use --exec-on-remove. It is the udisks daemon that was unmounting and removing the mount point on removal. But I'll consider adding that to devmon too. When used with udevil, it won't work yet because there were some issues with unmounting missing devices, so that is not possible yet.

udevil does remove the mount point when unmounting if it created it. But it's not a daemon, so if you unmount the device another way, the mount point will remain. You can use 'udevil clean' to remove leftover udevil-created mount points (in all configured media directories).

EDIT: Also note that devmon has some convenience options for unmounting. These can be associated with a key shortcut in your window manager - so you press the key shortcut, then remove the device. This has the advantage that the device is removed safely. See devmon --help (--unmount-recent, --unmount-optical, and --unmount-all). These might help until udevil can unmount missing devices.

I decided to try udevil and it seems to work for the most part. I do have a couple questions:

1. Are the instructions for mounting NTFS-3g valid for Arch Linux? Since ntfs-3g provides both mount.ntfs and mount.ntfs-3g, I suppose I would have to delete the former file before I can create the link. Also you might want a reminder on the website that for Arch Linux, mount.* is located under /usr/bin/ not /sbin/.

If the mount.ntfs helper is present, this is probably already taken care of in Arch, as it is in other distros. If ntfs is mounted with ntfs-3g then you're set. Some distros don't create the link and thus ntfs is not mounted writable by default. I'll try to make that note clearer. It's mainly just to help people who don't know how to set ntfs to mount with ntfs-3g.

2. I have an external drive with two partitions (/dev/sdb1 and /dev/sdb2) and udevil mounts them fine. However before mounting the partitions, it also tries to mount the entire device too (/dev/sdb). It seems harmless (it just fails) but is there a way to tell it to stop doing that?

I assume you mean devmon mounts them all, as udevil only mounts what you tell it to. devmon is very aggressive about trying to mount things so that it works with almost all devices - udev doesn't always give accurate info on filesystems present, so the alternative is to have it not try when in fact a device is mountable. That's why some automounters refuse to react to some devices when devmon mounts them. The only reliable way to know is to try it (if some conditions are met, such as media being present). If you want to avoid it, you could tell devmon to ignore the device with '--ignore-device /dev/sdb' But normally that output isn't even seen, so you can safely ignore it.

Thanks for looking into it ... udevil 0.2.3 now emulates udisks2 behavior wrt /run/media/$USER - it will be created on demand and the acl set. If setfacl fails, it will fallback to rwxr-xr-x, as rwxr-x--- wouldn't allow the user to access it. Let me know if that solves the issues you had.

That's excellent - latest version seems to work fine.

IgnorantGuru wrote:

udevil loosely emulates udisks v1 output, not udisks2. I won't be following udisks2 for most things, because the developers keep changing it at random, and warn that the output may be inconsistent.

Okay - sticking to udisks1 makes sense, and I would agree that udisks2 has become a pain. So, no need to add "Unmounted..." output.

IgnorantGuru wrote:

The 'mount: block device /dev/sr0 is write-protected' is output by mount - you can avoid that message by adding the ro option to /dev/sr0's entry in fstab, or if not present, by adding 'ro' to the default options for the fstype (eg iso9660) in udevil.conf. udevil doesn't censor mount's output.

Understood, and I have successfully added 'default_options_iso9660 = ... ro' as you suggest.

IgnorantGuru wrote:

Also, udevil.conf should no longer be overwritten by the AUR package. The first time you install the new package, it may copy your udevil.conf to pacorig - not sure. In any event, make a backup before testing.

When I installed the latest version of udevil-git, it sensibly created /etc/udevil/udevil.conf.pacnew, preserving udevil.conf itself.

Thanks very much for addressing these points so swiftly.Much appreciated

If the mount.ntfs helper is present, this is probably already taken care of in Arch, as it is in other distros. If ntfs is mounted with ntfs-3g then you're set. Some distros don't create the link and thus ntfs is not mounted writable by default. I'll try to make that note clearer. It's mainly just to help people who don't know how to set ntfs to mount with ntfs-3g.

Thanks for the clarification.

IgnorantGuru wrote:

If you want to avoid it, you could tell devmon to ignore the device with '--ignore-device /dev/sdb' But normally that output isn't even seen, so you can safely ignore it.

Thanks that worked. BTW are ignored devices separate for devmon and udevil?

udevil doesn't actually ignore devices. But you can choose allowed_devices and forbidden_devices in udevil.conf. In your case ignoring in devmon is what you want, since udevil will throw an error if a device is forbidden or not allowed. Actually, I don't recommend ignoring sdb because you might plugin another device that is partitionless and the fs will be on sdb - you might wonder why devmon ignores it. The failed mount attempts are normal. But up to you of course, just wanted to warn you that not all devices are partitioned.

Would it be possible to add sshfs support to udevil? I can't mount my university's sftp drive without using that, gvfs, or whatever KDE uses to mount sftp stuff.

Indeed this is a natural extension - just hasn't been addressed. If you want to speed the process along, I could use examples of the mount command for sshfs, preferably using mount directly and probably relying on a mount helper. IOW what command does udevil need to issue to mount given this command to udevil:

udevil mount sshfs://user:password@host/share

Also, what allowed and default options should be added to udevil.conf for sshfs, and what additional packages would be required. This is the research I need to do on it. I was planning to look into lufs and how that might centralize support for several protocols, maybe adding a lufs based ftp, etc. as well. Maybe just adding generalized lufs support will be the most efficient approach. But I do prefer it go through mount, even via helper, rather than a separate program (for example udevil runs mount not curlftpfs). I would consider a separate program, but I would rather have udevil just deal with mount, and this makes a central point for the user to configure the system's support types.

So that's where sshfs is - needs some research and then the coding should be minor. I do have some things pending in spacefm before I get back to udevil.

No. Cyrillic letters in file/folder names. They are shown as `???????', when stick mounted by udevil. And if there are several folders with the same name length, you can open only one, regardless of which folder you click in FM, because they are all named `??????'

IgnorantGuru wrote:

I'd like to see the output of these commands, replacing sdX with the correct device file:

It does'nt work because the miss of mount.smbfs (mount.cifs exist)"ln -s mount.cifs mount.smbfs in /sbin" does the job but it is weird !

Thanks - I did receive some feedback on this issue and will take a look. Does anyone know if smbfs is deprecated and cifs prefered? For example Debian has mount.smbfs (not a link) as well as mount.cifs, but Arch only has mount.cifs.

In /etc/udevil.conf, allowed_options_smbfs = ... uid=$UID, .... is useless because the option is replaced by the true uid and then rejected by udevil, so uid=* is the only workaround !

Not sure why it would be rejected, but it does replace $UID before checking if the option is valid. Can you show an example of the command you're issuing (with --verbose)? Are you trying to pass it a UID option on the command line?

The idea of uid=$UID is that the user running udevil can only set the uid option to their own uid. Or if it's a default option, then it is added automatically. You can also hard code uids in the allowed_options, eg uid=1000, but this has limited use unless you're using a separate udevil.conf for each user.

I'll look at the utf8 as a default option for some fstypes - was hoping for some feedback on this issue. I wonder why in some cases it is added automatically - a system config somewhere perhaps.