Using fstab instead of autofs for a samba share

A few weeks ago, I borrowed a Raspberry Pi 4B from a friend. Since it wasn't going to be used for a while, I decided to set up a network storage for our home network. It seemed like the most practical use for the Pi.

The Problemo

Everything was working great until today. After a quick look at the service status, here's what I was dealing with:

Sep 14 03:06:13 homeserver systemd[1]: Starting smb.service - Samba SMB Daemon...
Sep 14 03:06:14 homeserver systemd[1]: Started smb.service - Samba SMB Daemon.
Sep 14 03:06:26 homeserver smbd[2421]: [2025/09/14 03:06:26.137220,  0] ../../source3/smbd/smb2_service.c:746(make_connection_snum)
Sep 14 03:06:26 homeserver smbd[2421]:   make_connection_snum: canonicalize_connect_path failed for service SharedDrive, path /mnt/jantolentino_Drive/jantolentino_Drive
Sep 14 10:21:14 homeserver smbd[3609]: [2025/09/14 10:21:14.823284,  0] ../../source3/smbd/smb2_service.c:746(make_connection_snum)
Sep 14 10:21:14 homeserver smbd[3609]:   make_connection_snum: canonicalize_connect_path failed for service SharedDrive, path /mnt/jantolentino_Drive/jantolentino_Drive
Sep 14 10:22:21 homeserver smbd[3740]: [2025/09/14 10:22:21.111827,  0] ../../source3/smbd/smb2_service.c:746(make_connection_snum)
Sep 14 10:22:21 homeserver smbd[3740]:   make_connection_snum: canonicalize_connect_path failed for service SharedDrive, path /mnt/jantolentino_Drive/jantolentino_Drive

The key error is canonicalize_connect_path failed, which pointed to an issue with Samba accessing the drive's path.

Initial setup

The Raspberry Pi 4 has Fedora Server 38 running on it. I installed Samba, configured the firewall, and assigned a static IP address to the device on my network.

I did, however, run into a couple of snags setting up the external storage. My drive is formatted with BTRFS and encrypted with a passphrase. I discovered two headaches:

1. External drives often unmount automatically after a period of inactivity to save power and extend their lifespan.
2. When my encrypted drive unmounts, it needs the passphrase to be unlocked and mounted again.

Having to manually enter my password every time the drive went idle would defeat the purpose of an always-on network share. Plus, I'm not always on a computer which I can easily access the server's terminal.

After some reading online, I found a two-part solution: autofs and crypttab. The autofs service automatically remounts a drive when it's accessed, which works perfectly with Samba. To handle the password issue, crypttab securely "caches" the passphrase and uses it to unlock the drive when needed.

This setup gave me an awesome network storage solution that worked flawlessly for a few weeks. Until today.

Where It Went Wrong

After some digging, it looked like a race condition. The Samba service was trying to access the share before autofs had finished unlocking and mounting the encrypted drive. This timing issue was the root of the problem. Because Samba couldn't find the path, it failed.

I needed a different approach that wouldn't have this race condition.

The Fix: fstab

As it turns out, a much simpler solution is already built into Fedora (oops): fstab. It's powerful enough to handle everything I needed by ensuring the drive is mounted at boot time, well before Samba starts.

First, I had to undo my autofs configuration.

# Remove autofs and its config
sudo dnf remove autofs
sudo rm /etc/auto.jantolentino_Drive

Next, I created a permanent mount point for the drive.

sudo mkdir -p /mnt/jantolentino_Drive

Configuring fstab was surprisingly easy. I just added the following line:

# /etc/fstab
/dev/mapper/jantolentino_Drive /mnt/jantolentino_Drive btrfs defaults,nofail 0 2

The nofail option is important here; it prevents the system from hanging during boot if the drive isn't connected.

Finally, I updated my Samba configuration to use the new static mount point.

[jantolentino_share]
  comment = SharedDrive
  path = /mnt/jantolentino_Drive

Then, a quick reboot.

The Result

We now have a working setup again. This approach feels much more stable, and hopefully, it works for the long run

jantolentino@homeserver:~$ sudo systemctl status smb.service
[sudo] password for jantolentino:
● smb.service - Samba SMB Daemon
     Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2025-09-15 00:00:43 EDT; 2 months 21 days ago
 Invocation: 346b968c905f4c2ebd09a4e14162382e
       Docs: man:smbd(8)
             man:samba(7)
             man:smb.conf(5)
   Main PID: 1453 (smbd)
     Status: "smbd: ready to serve connections..."
      Tasks: 3 (limit: 4124)
     Memory: 2.5G (peak: 2.8G)
        CPU: 4min 59.375s
     CGroup: /system.slice/smb.service
             ├─1453 /usr/bin/smbd --foreground --no-process-group
             ├─1511 /usr/bin/smbd --foreground --no-process-group
             └─1512 /usr/bin/smbd --foreground --no-process-group

Sep 15 00:00:42 homeserver systemd[1]: Starting smb.service - Samba SMB Daemon...
Sep 15 00:00:43 homeserver systemd[1]: Started smb.service - Samba SMB Daemon.

Final Thoughts

There are probably other ways to approach this, but I'm happy that things are in a better state and my files are secure. I also scheduled some BTRFS maintenance jobs like scrubbing to keep the drive healthy. I'll probably look more into my setup. But for now, everything's well.