udevil will not unmount an ejected disc

[OmegaPhil]

See topic - from SpaceFM/udevil's perspective the user is expected to Remove the device, but this is not normal behaviour (the user expects to manually eject the drive and remove the media, and the OS/programs Just Know).

This means that tabs containing the previous disc's contents are not closed, and attempts to browse a newly-inserted disc on these tabs fail because udevil/spacefm considers the disc already mounted.

You can kill all these tabs then try again - then it seems the old media directory remains but the contents is from the new disc.

[OmegaPhil]

The optical device in question does not have an fstab entry - this is dynamically-mounted media.

[arclance]

I think this is a duplicate of Issue #6 "directory created when automounting dvd/cd not removed when disk is ejected"

[OmegaPhil]

Its similar, but not concerned with cleaning up. I have tested the code thats supposed to fix your issue and it still has this one.

[IgnorantGuru]

What's happening here is you don't have an entry in fstab that allows the normal user to unmount /dev/sr0. So when you press eject without unmounting first, the media is removed. When udevil tries to unmount it, it cannot determine the fstype (since the media is gone), so it won't grant permission for the user to unmount. (udevil.conf rules are based on the fstype)

You can add an entry like this to fstab (and create /media/dvd as root as a permanent mount point for discs) to give user permission to unmount:

/dev/sr0     /media/dvd   auto    ro,user,noauto,unhide   0      0

Or you can right-click on the device in spacefm and select Remove (or middle-click on it), which unmounts and ejects.

I'll take a look a udevil's rules and see what can be done to grant permission to unmount media-removed devices. But since media detection doesn't always work as expected, this criteria alone can't be used reliably.

[arclance]

I just tested the fix for issue #6 for spacefm and it does not work. I suspect these bugs are related if they are not duplicates.

[arclance]

Why does udevil need to know the fstype to unmount it?

[IgnorantGuru]

Why does udevil need to know the fstype to unmount it?

What udevil allows and doesn't allow depends on udevil.conf settings, some of which depend on the fstype. eg allowed_users_vfat = xxx

It would be enough to say that since the media is removed, any user can unmount it, if media detection was reliable in udev, etc. But it's not. So without the fstype you're basing a security rule on something which is unreliable. And since udevil is not a daemon it doesn't keep track of who mounted the device - it gather its information on the device each time it's run.

I need to look over the code before I can say what might be done for this.

[IgnorantGuru]

I edited the OP title to reflect the fact that the issue here involves attempting to unmount a disc that has already been ejected.

To clarify, udevil is not a daemon - it does not run continuously and take an action when eject occurs. SpaceFM or devmon take actions when eject occurs. For example, they may run 'udevil umount' to unmount the ejected disc.

But in this case the user cannot gain permission for the unmount to occur. udevil responds:

$ udevil umount /dev/sr0
udevil: error 64: unable to determine device fstype - specify with -t

(Specifying -t won't be accepted - that error message is used by both mount and unmount, but unmount does not accept -t.)

[IgnorantGuru]

udevil next branch now reads the fstype of an ejected disc from mtab if no udev property is found for this, which should allow you to unmount ejected discs. (My tests in spacefm now have this working. When spacefm detects an eject, it will attempt to unmount it.)

[IgnorantGuru]

devmon 1.1.3 (in udevil next) should now handle unmounting an ejected disc as well.