A boot-time mount assumes the world is ready at boot: network up, server awake, right building. Laptops live differently - they sleep, they roam, Wi-Fi joins after login. Automount stops asking the share to exist at boot and simply creates it the moment you actually open the folder.
The pattern is familiar: the share is perfect all morning, the laptop sleeps over lunch, and the afternoon starts with a frozen file manager or a folder that is suddenly empty. Or the laptop boots at home, nowhere near the office PC, and the mount silently never happens. A normal fstab mount is a one-time event tied to boot and network state - it does not heal itself when the world changes. systemd automount changes the trigger: the folder sits there as a placeholder, and the first access mounts the share on demand. It is a small edit to the line you already have, and for laptops it is usually the end of this whole class of problems.
Three everyday events defeat a boot-time mount. Sleep and suspend drop and rebuild the network, leaving the mount pointing at a connection that no longer exists - the folder hangs or shows empty. A boot on a different network - home instead of office - means the server simply is not there when the mount is attempted, and nofail lets the boot proceed without it, permanently for that session. And a slow Wi-Fi that joins after login misses the _netdev moment entirely. In each case nothing retries. That missing retry is the whole problem.
Edit sudo nano /etc/fstab and adjust the options of your existing line - same server, same mount point, same credentials.
noauto - do not mount this at boot in the old wayx-systemd.automount - create an automount unit that watches the folder and mounts on first accessx-systemd.idle-timeout=60 - unmount again after sixty idle seconds, so the connection is dropped cleanly instead of going stale while the laptop sleeps (the number is seconds; raise it if you prefer a longer hold)_netdev and your uid and gid - they still apply to the mount when it happensAutomount units are generated from fstab, so the reload matters here more than anywhere.
sudo systemctl daemon-reloadsudo umount /mnt/SharedDocs - the folder now looks empty, which is the placeholder doing its jobls /mnt/SharedDocs - a short pause, then the files appear. That pause is the mount happening on demandsystemctl status mnt-SharedDocs.automount shows the watcher, and the matching .mount unit shows active while you use itAutomount trades boot-time certainty for on-demand resilience, and two small behaviours come with it. The first open of the folder after a while takes a second or two while the mount happens - noticeable, not a fault. And a program that scans the folder the instant it starts can still occasionally win the race and report the folder empty; opening the folder once in Files before starting that program settles it. In exchange, sleep stops mattering, the wrong network stops mattering, and a server that was off at boot joins the moment you reach for it.
nofail thinking with you: an unreachable server now means the first access pauses and fails, instead of the whole boot stalling - the failure moved to the right momentWatch the video to see the permanent setup from the start - and consider the automount variant if your machine is a laptop.
Watch Full VideoYes - that is its purpose. Because the idle timeout lets the mount drop while the machine sleeps, the next time you open the folder the automount simply mounts it again, fresh, on whatever network you woke up on. There is no stale connection left to hang your file manager.
No. The timeout counts idle time - the mount is released only after the folder has sat unused for the period you set, and open files keep it alive. If you find the pause on reopening annoying, raise the number in x-systemd.idle-timeout; the value is a comfort setting, not a correctness one.
Very likely. _netdev waits for the network to be online, but on many laptops the wireless connection is tied to the user session and joins after the mount was already attempted. The boot then finishes without the share, and nothing retries. Automount removes the race entirely - the mount waits for you, not for the boot sequence.