When a FUSE filesystem is unmounted externally (e.g. umount <mountpoint>), the session loop exits because the kernel closes the fd. Session then drops, which triggers UmountOnDrop::drop, which attempts to unmount an already-unmounted mountpoint and logs:
WARN fuser::session: Failed to umount filesystem: Invalid argument (os error 22)
#589 fixed the double-unmount case (explicit Mount::umount() followed by Mount::drop), but this is a different code path. Here nobody calls UmountOnDrop::umount() explicitly — the only call comes from UmountOnDrop::drop. At that point Mount still holds Some(MountImpl), so it proceeds to umount_impl() which fails with EINVAL.
The Mount::drop in mnt/mod.rs already acknowledges this scenario in its comment:
// This is not necessarily an error: may happen if a user called 'umount'.
warn!("Unmount failed: {}", err);But the UmountOnDrop::drop in session.rs doesn't have the same tolerance:
impl Drop for UmountOnDrop {
fn drop(&mut self) {
if let Err(e) = self.umount() {
warn!("Failed to umount filesystem: {}", e);
}
}
}Since external unmount is a normal operational scenario (cleanup scripts, container teardown, etc.), this could be downgraded to debug!, or the EINVAL case could be silenced specifically.
fuser 0.17.0, Linux (Ubuntu 24.04 in Docker).
When a FUSE filesystem is unmounted externally (e.g.
umount <mountpoint>), the session loop exits because the kernel closes the fd.Sessionthen drops, which triggersUmountOnDrop::drop, which attempts to unmount an already-unmounted mountpoint and logs:#589 fixed the double-unmount case (explicit
Mount::umount()followed byMount::drop), but this is a different code path. Here nobody callsUmountOnDrop::umount()explicitly — the only call comes fromUmountOnDrop::drop. At that pointMountstill holdsSome(MountImpl), so it proceeds toumount_impl()which fails with EINVAL.The
Mount::dropinmnt/mod.rsalready acknowledges this scenario in its comment:But the
UmountOnDrop::dropinsession.rsdoesn't have the same tolerance:Since external unmount is a normal operational scenario (cleanup scripts, container teardown, etc.), this could be downgraded to
debug!, or the EINVAL case could be silenced specifically.fuser 0.17.0, Linux (Ubuntu 24.04 in Docker).