Ubuntu Hangs at Boot After Adding a Share The nofail and netdev Fix
The share mounted perfectly when you tested it. Then you rebooted, and Ubuntu hung for minutes - or landed in emergency mode asking for the root password. Nothing is broken: your fstab line asks for a network device before the network exists, and systemd waits, stubbornly, for an answer.
Technical AnshuUbuntu and WindowsStep-by-step guide
Watch the video for the complete process shown live, step-by-step
This is the most common way a correct share setup turns into a scary morning. At your desk the network was up and the Windows PC was awake, so mount -a succeeded. At boot the order is different: fstab entries are processed early, the network may not be ready for several more seconds, and the Windows PC may be switched off entirely. A network mount without the two safety options makes your whole login wait on another machine's power switch. This page first gets you back into a working system, then fixes the line so it can never hold boot hostage again.
✓ _netdev - wait for the network ✓ nofail - boot on without the share if it cannot mount
Two options change everything. The share still mounts whenever it can - it just stops being able to block the machine when it cannot.
1
Why It Happens - a Mount Asked Too Early, of a Machine That May Be Off
Local disks exist the instant the machine powers on. A network share exists only when three things are all true: the network is up, the other machine is on, and the share is reachable. A plain fstab entry assumes all three at the moment it is processed. systemd, doing its job literally, waits for the mount to succeed or time out - the default wait is long, and a failed mount marked as required can send the boot to emergency mode.
Two different causes produce the same hang: network not ready yet, or the Windows PC genuinely off. The fix covers both
A laptop carried away from the office network guarantees this failure on every boot until the line is fixed
2
Get Back In - Comment the Line Out First
If you are staring at an emergency shell or a root maintenance prompt, recovery is quick because fstab is just a text file.
At the emergency prompt, remount the root filesystem writable: mount -o remount,rw /
Open the file: nano /etc/fstab
Put a # at the start of the share line - that comments it out, so this boot and the next ignore it
Save, then continue or reboot: systemctl reboot. Ubuntu should come up normally, without the share
If the machine is only slow, not stuck: let it finish once, log in, and fix the line from your desktop instead
3
The Cure - Add _netdev and nofail to the Options
With the system healthy, edit the line properly - uncomment it and fix its options in the fourth field, where all the comma-separated mount options live.
_netdev tells systemd this device needs networking: delay the mount until the network is online, instead of racing it
nofail tells systemd the boot does not depend on this mount: if it still fails, continue without the share and let the user log in
The line should now read like the after example above - same server, same credentials file, two extra words in the options
Save with the same editor, then sudo systemctl daemon-reload so the change is registered
4
Test Both Worlds Before You Call It Fixed
The fix has to survive two opposite mornings, so test both while you are watching.
Server ON test: sudo umount /mnt/SharedDocs then sudo mount -a - the share mounts, files visible
Server OFF test: shut down or disconnect the Windows PC, reboot Ubuntu - login must arrive at normal speed, with the share simply absent
If the share must reappear by itself when the server returns - instead of waiting for your next reboot - that is the automount pattern, covered in its own page in this series
🔴 The honest price of nofail: it hides failure. On a morning when the office PC is down, Ubuntu boots happily and the share is just not there - and an app may report a missing file instead of a missing server. That is still the right trade for a desktop, but know which silence you bought: check the share exists before blaming the application.
Watch the Complete Video Guide
Watch the video for the complete permanent setup with these safety options included from the start.
Long enough to feel broken - systemd waits on a required device with a timeout in the range of ninety seconds, and retries or related units can stretch the total delay to several minutes before emergency mode. The delay is the system being patient, not damaged. Adding nofail removes the share from the boot's critical path entirely.
Is _netdev on its own enough?
No. _netdev only fixes the timing - the mount now waits for networking. It does nothing for the second cause, the Windows PC being switched off or the laptop being on a different network. That case needs nofail (boot without it) or an automount (mount it later, on first use). Most desktop setups want _netdev and nofail together.
Emergency mode says the root filesystem is read-only. Why?
Emergency mode mounts the root filesystem read-only as a safety measure while it waits for you. The remount command on this page, mount -o remount,rw /, makes it writable so you can edit fstab. If even that fails, boot from Ubuntu install media, mount the disk from there, and comment the share line out from the live session instead.
This guide is based on the Technical Anshu video on mounting a Windows share in Ubuntu - stuck on any step, ask in the video comments and you will get an answer.