I have a few Ubuntu 19.04 (soon to be 19.10) systems running systemd, and they all mount NAS-served mounts using systemd units. I'm also using automount units to make sure the mounts are only mounted on demand.

However, I have an interesting conundrum with Gnome Shell. After resuming from suspend, if the mounts aren't available, Gnome Shell will refuse to unlock quickly and will hang for a few minutes. It will eventually come to, but I'd just as soon do away with the delay.

Currently, both the mount units and automount are set BindsTo=networking-online.target, under the assumption that networking is taken down when suspend starts up. This assumption appears flawed.

What I'd like to have happen is have both the mount and automount units stop on suspend, and start up again on resume.

Granted: the real issue here is to figure out why Gnome is freaking out about not having some network mounts available (I haven't been able to figure out why it's doing this!! and this is frustrating!). However, since that's probably harder to fish out, I figured I'd go for a workaround first.

So...any suggestions?

Here's an example of one of the mount units:

Description=Network Stuff Directory



And here's its accompanying automount unit:

Description=Automount Network Stuff Directory



Of the above units, only the automount unit is enabled (i.e. set to autostart on boot), since the mount unit is meant to be started by the automount unit.


1 Answer 1


I am pretty late here, but I had a more or less similar requirement. I had several drives mounted using systemd, and Fedora used to hang when waken up from a suspended state.

I created a script /usr/lib/systemd/system-sleep/drive-mount-problem.sh on my Fedora laptop having the below content:

# Script to unmount and mount Windows drives on Linux system
if [ "${1}" == "pre" ]; then
    sudo systemctl stop windows-application.mount
    sudo systemctl stop windows-os.mount
    sudo systemctl stop windows-personal.mount
elif [ "${1}" == "post" ]; then
    sudo systemctl start windows-application.mount
    sudo systemctl start windows-os.mount
    sudo systemctl start windows-personal.mount

I found that the problem was resolved with this (although I had to give rights on user's account for executing the systemctl start and stop commands on those mount points).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .