AutoFS on Linux: Automatically Mount and Unmount Network Drives (NFS/Samba) Flexibly and Reliably

Background: Why fstab Isn’t Always the Best Choice

When I first started as a sysadmin, I had a habit of throwing all network drives (NFS or Samba) into /etc/fstab. My thinking was: “Mount everything at boot — nice and reliable.” But reality had other plans. One afternoon, the NAS storing our backups suddenly lost power. The result: every server with a mount from that NAS started hanging. The df -h command froze with no response. SSH logins wouldn’t complete — the system just sat there waiting for a response from a dead drive.

The problem with /etc/fstab is that it performs a “static” mount. If the network becomes unstable or the remote server restarts, the client will hang for a long time. That’s when I realized I needed AutoFS.

AutoFS only mounts a drive when you actually access that directory. Not using it? After 60 seconds (configurable), it unmounts automatically. The real-world result: a network drive losing power at 3 AM no longer takes the entire system down with it.

Installing AutoFS

After about 6 months running AutoFS in production, I’ve found it remarkably lightweight. One daemon, a few config files — no special kernel modules, no building from source.

On Ubuntu/Debian:

sudo apt update
sudo apt install autofs nfs-common cifs-utils -y

On RHEL/CentOS/AlmaLinux:

sudo dnf install autofs nfs-utils cifs-utils -y

Quick note: You’ll need to install nfs-common (or nfs-utils) for NFS and cifs-utils for Samba — otherwise AutoFS will throw an error about an unrecognized filesystem type.

Detailed Configuration: How the Smart Setup Works

AutoFS configuration is typically split into 2 main files: the Master Map (defines the root mount point) and the Map File (specifies details about remote servers).

1. Configuring the Master Map

Open /etc/auto.master — this is where you declare the parent directory you want AutoFS to manage.

sudo nano /etc/auto.master

Add the following line at the end of the file:

/mnt/remote  /etc/auto.nfs  --timeout=60 --ghost

• /mnt/remote: The root directory on the local machine.
• /etc/auto.nfs: The detailed config file (we’ll create this in the next step).
• --timeout=60: After 60 seconds of inactivity, it will automatically unmount.
• --ghost: Shows subdirectories even when not yet mounted (very handy — you can see them with ls right away).

2. Configuring the Map File for NFS

Now, create the file /etc/auto.nfs to specify which server mounts where.

sudo nano /etc/auto.nfs

File contents:

backup  -fstype=nfs,rw,soft,intr  192.168.1.100:/data/backup
data    -fstype=nfs,rw,soft,intr  192.168.1.100:/data/public

When you access /mnt/remote/backup, AutoFS automatically connects to 192.168.1.100. I always use the soft,intr options for NFS — if the server dies, the client returns an error immediately instead of hanging indefinitely.

3. Configuring the Map File for Samba (Windows Share)

If you need to mount a drive from Windows or a NAS running Samba, the configuration differs slightly in the authentication section. Create the file /etc/auto.samba:

shared_folder -fstype=cifs,credentials=/etc/creds_samba,iocharset=utf8 ://192.168.1.50/Shared

And don’t forget to create a file to store the credentials securely:

sudo nano /etc/creds_samba

username=your_user
password=your_password
domain=your_domain

Remember to set permissions so only root can read this file: sudo chmod 600 /etc/creds_samba. Early on, I completely forgot about this and left it at 644 — which exposed the backup account’s password for everyone to see. Don’t make the same mistake.

Testing and Monitoring

Restart the service to apply the new configuration:

sudo systemctl restart autofs
sudo systemctl enable autofs

The quickest way to test is to actually access the directory:

cd /mnt/remote/backup
ls -l

If files appear, you’re good. Use mount | grep autofs to check the current mount status in detail.

Debugging Errors

Accessing a directory that throws an error or just hangs? Don’t panic. Stop the service and run AutoFS in foreground mode to see logs in real time:

sudo systemctl stop autofs
sudo automount -f -v

At this point, every error — wrong permissions, wrong server IP, wrong NFS version — will show up in detail right on the terminal. This is my go-to approach for tackling the tricky cases when dealing with legacy systems.

Monitoring via System Logs

During long-term operations, I regularly check logs via journalctl to know when drives get unmounted or when there are network connectivity issues:

journalctl -u autofs -f

Closing Thoughts from Real-World Experience

Honestly, I didn’t expect such a small config change to solve so many problems. Since switching to AutoFS, the anxiety of doing NAS maintenance while servers are still running has nearly disappeared. Before, I had to announce it ahead of time, notify the whole team, then pray. Now I just shut it down — clients get an I/O error on access instead of dragging the entire SSH session down.

It took me about half a day to test and configure it the first time. In return, I’ve had over 2 years of barely worrying about servers hanging due to unexpected network drive failures. For anyone managing servers with network mount points, this upgrade is absolutely worth the effort.