Is it possible to delay autounmounting a partition during shutdown?

phill123 · 2025-11-14 00:24:44

I've got my system set up with my Arch partition and a Windows partition side by side. There's also a third exFAT partition which both OSes share where I keep music and so on. The problem I have is that if I forget to close a media app before rebooting the machine, it fails to unmount that partition properly. I think this means it's trying to unmount the partition before the user session is terminated, but I honestly have no idea why it would behave this way or how to fix it.

The relevant line from /etc/fstab is this:

UUID=77DD-F64C /home/media auto    rw,gid=1001,dmask=0007,fmask=0117,nodev,nosuid,nofail 0 0

And I'm a newbie so I'm really not sure where to go looking next. Searching online hasn't been very helpful, probably because I have no idea what the right keywords are.

dagorret · 2025-11-14 00:30:55

Mounting the shared partition inside /home is what causes the problem.

Systemd unmounts user mounts before /home, and since it's inside /home, it can become locked.

phill123 · 2025-11-14 03:28:42

I just tried /mnt/media and /media and both those paths have the same problem. Where should I be moving it to (if this is actually the problem)?

/home, btw, is just a folder in / - it's not its own partition on this machine.

Jristz · 2025-11-14 03:51:13

maybe a custom systemd service that depend on the umount of the previous partition?

dagorret · 2025-11-14 05:07:11

I would mount that folder in /media/data,
/mnt/shared, /run/media/$USER/shared.

Jristz wrote:

maybe a custom systemd service that depend on the umount of the previous partition?

You're right, the best option is to delay unmounting. I would do it in fstab. The option to delay unmounting due to inactivity is already available. See Automatic unmount version 3.1.4 in https://wiki.archlinux.org/title/Fstab# … ic_unmount

.

seth · 2025-11-14 09:00:47

The problem I have is that if I forget to close a media app before rebooting the machine, it fails to unmount that partition properly.

If the "media app" keeps files on the partition open, it's not inactive.

@phill123, what is a "media app" specifically and why does it not terminate before the umounts?
In doubt please post your complete system journal for an affected boot eg.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous ("-1") one.

phill123 · 2025-11-23 14:11:05

A "media app" is usually VLC, but other media apps I've tried out (Elisa's one I remember) have done it too. I often just have something just playing in the background and I sometimes forget to shut it down before rebooting the system - especially when it's paused and I forget it's even on. I don't think there's anything particular about which app it is or that it's a media app, it just happens to be media apps triggering this for me because (for now) that happens to be the sort of files I have living off on their own partition separate from /.

seth wrote:

why does it not terminate before the umounts?

I have no idea. Looking at the logs (https://0x0.st/KVkA.txt) it seems that the system tries to unmount that partition almost immediately afterit begins to terminate my user session. The app (in this case VLC) doesn't seem to have even noticed that anything is happening yet at this point. Ideally the session and all of its processes would be fully shut down before the system even attempts to unmount that partition (and that's the default that I'd expect, so I'm guessing I failed to configure something properly).

(Sorry for the slow reply. Life stuff.)

seth · 2025-11-23 15:04:26

Nov 23 06:28:32 mekkatorque localsearch-3[4070]: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts
Nov 23 06:28:32 mekkatorque umount[13763]: umount: /media: target is busy.

The drive is mounted through gvfs and vlc then only later dies w/ xwayland - https://wiki.archlinux.org/title/VLC_me … nd_support but I'm not even sure whether that would help much.

Unfortunately

Nov 23 06:28:32 mekkatorque systemd[3466]: org.gnome.Shell@wayland.service: Consumed 24.482s CPU time, 425.8M memory peak.

ends even later, but you're looking for ways to run some script when gnome terminates so you can kill vlc early on.
An alternative path would be to not mount that partition in the session but via an fstab entry.

phill123 · 2025-11-23 23:16:32

seth wrote:

you're looking for ways to run some script when gnome terminates so you can kill vlc early on.

Not really? I eventually want to use this partition for more than just my media library, so maintaining some list of programs that need to be specially shut down feels like it's going to turn out kinda fragile. And I ultimately want it to just do the correct thing and wait until all user sessions (and all their processes) are done before it unmounts this partition. If it can do that with the root partition then surely there's some way to do that with all partitions on that drive.

seth wrote:

An alternative path would be to not mount that partition in the session but via an fstab entry.

It is in my fstab. The entry's below (same one I started with, just a different mount path). What's wrong with it? I don't see anything in the fstab manpage that explains why the system wants to unmount it so quickly.

UUID=77DD-F64C /media auto    rw,gid=1001,dmask=0007,fmask=0117,nodev,nosuid,nofail 0 0

seth · 2025-11-23 23:34:50

And I ultimately want it to just do the correct thing and wait until all user sessions (and all their processes) are done before it unmounts this partition.

Don't use gnome…

Does gvfs leave it alone w/ a different mount point?
https://wiki.archlinux.org/title/File_m … _displayed

nofail

Is the drive permanently attached?

phill123 · 2025-11-23 23:58:11

Yeah, the drive's permanently attached. It's on the same device that the root folder's on.

So far I've tried mounting it to /home/media, /mnt/media, and /media. Let me go find out if the problem is just any path that has "media" in it. Edit: nope, /abcdefg behaves the same.

Last edited by phill123 (2025-11-24 00:02:27)

seth · 2025-11-24 08:15:17

Does explicitly adding "x-gvfs-hide" to the mount options make gvfs-udisks2-volume-monitor ignore it?

I don't quite get why it's not treated as internal device itfp, you might want to completely https://wiki.archlinux.org/title/Udisks … partitions

phill123 · 2025-11-29 23:14:31

x-gvfs-hide by itself didn't change anything. But this seems to have fixed things:

$ cat /etc/fstab
# <snip>
UUID=77DD-F64C /mnt/shared_data auto    rw,gid=1001,dmask=0007,fmask=0117,nodev,nosuid,nofail,x-gvfs-hide 0 0

$ cat /etc/systemd/system/mnt-shared_data.mount 
[Unit]
Description=/mnt/shared_data
Before=local-fs.target
After=swap.target

[Mount]
What=UUID=77DD-F64C
Where=/mnt/shared_data
Type=exfat
Options=rw,gid=1001,dmask=0007,fmask=0117,nodev,nosuid,nofail

[Install]
WantedBy=multi-user.target

I still have no idea what was wrong in the first place or why this was necessary, or even if this fix ("fix"?) is a good idea. But it's what I've got for now. If I don't trip over any issues with it in the coming week (and nobody who knows better calls it out as a dumb idea) then I'll come back and mark this thread solved.

seth · 2025-11-30 10:04:33

The custom(?) mnt-shared_data.mount should™ render the fstab entry void, what does

mount

report about the actual parameters?
As to why this would do anything about gvfs (but hiding it don't) I've no idea - it doesn't seem to make any sense to me.

phill123 · 2025-12-02 12:02:56

I have no idea what's going on myself or why aggressively unmounting a fixed drive would ever be the default in the first place.

$ mount
<snip>
/dev/nvme0n1p8 on /mnt/shared_data type exfat (rw,nosuid,nodev,relatime,gid=1001,fmask=0117,dmask=0007,allow_utime=0020,iocharset=utf8,errors=remount-ro)

I don't see the x-gvfs-hide option there so I'm guessing that means the systemd unit has taken total precedence over fstab. I've got a second machine with a similar setup and the same problem so I can do some more experimenting there if there's anything else you think's worth trying. Otherwise once I'm happy this is a stable fix it's getting copy-pasted over to it.

seth · 2025-12-02 14:16:28

The problem is that gvfs-udisks2-volume-monitor gets interested in the device itfp, it wanting to then clean up "its stuff" when you log out seems kinda reasonable.

https://gitlab.gnome.org/GNOME/gvfs/-/issues/287 mentions that anything outside /media and everything having x-gvfs-hide should™ be ignored and indeed https://gitlab.gnome.org/GNOME/gvfs/-/b … tor.c#L671
But clearly not the case.

You might raise a bug at https://gitlab.gnome.org/GNOME/gvfs/-/issues because having a workaround is nice but not great - and if this ends up being some race condition, the workaround might pan out to be unreliable.

phill123 · 2025-12-03 05:11:01

I don't know if this actually is GVFS's fault. I know you snipped that line from my shutdown log right before the unmount error was reported, but this line appears well before it does:

Nov 23 06:28:32 mekkatorque systemd[1]: Unmounting /media...

I think this might be all systemd's doing. Looking at the autogenerated mount units on my other computer, I think the problem is that the one for my shared drive on it (which has a very similar fstab entry) is missing this line:

Before=local-fs.target

Experimenting with the explicit mount unit I created on this machine, that does seem to be where the magic is. And the reason it's missing is that apparently having "nofail" in my fstab options suppresses it. That Before= line looks like the difference between systemd aggressively unmounting the drive as soon as shutdown commences and it begins tearing down the multiuser target and having systemd unmount that partition at the very end, next to /boot.

If I find the time, I might try installing KDE at some point and seeing if I can repro the problem without Gnome.

seth · 2025-12-03 09:43:52

That's because of the nofail option, https://man.archlinux.org/man/systemd.m … pendencies
See the x-systemd.before=, x-systemd.after= options.

There's however indeed a peculiar order in your journal tail

Nov 23 06:28:32 mekkatorque systemd-logind[806]: System is rebooting.
Nov 23 06:28:32 mekkatorque systemd[1]: Stopped target Graphical Interface.
Nov 23 06:28:32 mekkatorque systemd[1]: Stopped target Multi-User System.
Nov 23 06:28:32 mekkatorque systemd[1]: Unmounting /media...
Nov 23 06:28:32 mekkatorque localsearch-3[4070]: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts
Nov 23 06:28:32 mekkatorque gnome-shell[3665]: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts
Nov 23 06:28:32 mekkatorque systemd[3466]: Stopped target Shutdown running GNOME Session.
Nov 23 06:28:32 mekkatorque systemd[1]: Stopped Session 3 of User phill.

multi-user.target and graphical.target are immediately stopped but gnome is still running - how do you start the session? GDM?

phill123 · 2025-12-03 13:01:23

Yeah, GDM. Specifically, graphical.target is my default boot target, it wants display-manager.service, and that's an alias for gdm.service.

Arch Linux

#1 2025-11-14 00:24:44

Is it possible to delay autounmounting a partition during shutdown?

#2 2025-11-14 00:30:55

Re: Is it possible to delay autounmounting a partition during shutdown?

#3 2025-11-14 03:28:42

Re: Is it possible to delay autounmounting a partition during shutdown?

#4 2025-11-14 03:51:13

Re: Is it possible to delay autounmounting a partition during shutdown?

#5 2025-11-14 05:07:11

Re: Is it possible to delay autounmounting a partition during shutdown?

#6 2025-11-14 09:00:47

Re: Is it possible to delay autounmounting a partition during shutdown?

#7 2025-11-23 14:11:05

Re: Is it possible to delay autounmounting a partition during shutdown?

#8 2025-11-23 15:04:26

Re: Is it possible to delay autounmounting a partition during shutdown?

#9 2025-11-23 23:16:32

Re: Is it possible to delay autounmounting a partition during shutdown?

#10 2025-11-23 23:34:50

Re: Is it possible to delay autounmounting a partition during shutdown?

#11 2025-11-23 23:58:11

Re: Is it possible to delay autounmounting a partition during shutdown?

#12 2025-11-24 08:15:17

Re: Is it possible to delay autounmounting a partition during shutdown?

#13 2025-11-29 23:14:31

Re: Is it possible to delay autounmounting a partition during shutdown?

#14 2025-11-30 10:04:33

Re: Is it possible to delay autounmounting a partition during shutdown?

#15 2025-12-02 12:02:56

Re: Is it possible to delay autounmounting a partition during shutdown?

#16 2025-12-02 14:16:28

Re: Is it possible to delay autounmounting a partition during shutdown?

#17 2025-12-03 05:11:01

Re: Is it possible to delay autounmounting a partition during shutdown?

#18 2025-12-03 09:43:52

Re: Is it possible to delay autounmounting a partition during shutdown?

#19 2025-12-03 13:01:23

Re: Is it possible to delay autounmounting a partition during shutdown?

Board footer