Sooner or later every homelab needs one machine’s disks visible on another: the NAS holding media for a Jellyfin box, a backup target, a shared documents folder for the household. Two technologies dominate that job on Linux, and they come from opposite worlds. NFS is Unix-native file sharing; Samba speaks SMB, the Windows file-sharing protocol. Choosing between them is mostly about who the clients are.

NFS: the Unix way

NFS exports a server directory and lets clients mount it like a local filesystem. Setup on the server side is one package and two lines:

sudo apt install nfs-kernel-server

# /etc/exports
/srv/media  192.168.1.0/24(ro,all_squash)
/srv/backup 192.168.1.50(rw,sync,no_subtree_check)

sudo exportfs -ra

The client mounts it:

sudo apt install nfs-common
sudo mount -t nfs nas:/srv/media /mnt/media

Note what was absent: usernames and passwords. Classic NFS trusts the network; access control is by client IP, and file ownership is mapped by numeric UID. That design gives NFS its two defining traits. It is fast and frictionless between Linux machines you control, and it is wrong for any network where you do not trust every host, since a laptop claiming the right IP and UID gets access. The UID mapping also produces the classic NFS surprise: files owned by UID 1000 belong to whoever UID 1000 happens to be on each machine, so keep UIDs consistent across your fleet or configure NFSv4 idmapd for name-based mapping.

Samba: the compatibility play

Samba implements SMB, so its shares work natively from Windows Explorer, macOS Finder, Linux file managers, and phone apps, with real username/password authentication:

sudo apt install samba

# /etc/samba/smb.conf (appended)
[media]
   path = /srv/media
   read only = yes
   guest ok = no
   valid users = alice, bob

[backup]
   path = /srv/backup
   read only = no
   valid users = alice

sudo smbpasswd -a alice   # Samba passwords are separate from Linux passwords
sudo systemctl restart smbd

Linux clients mount SMB shares with cifs-utils:

sudo apt install cifs-utils
sudo mount -t cifs //nas/media /mnt/media -o username=alice,uid=1000

Authentication is per-user, ownership on the client is whatever you set with uid=/gid= options, and nothing about the setup assumes the client is Unix. The cost is a protocol with more moving parts and, historically, more overhead, though modern SMB3 performs far better than Samba’s old reputation suggests.

Choosing between them

All-Linux environment, trusted LAN, performance matters (media serving, backup targets, VM storage): NFS. Any Windows or macOS clients, per-user authentication desired, household file sharing: Samba. Running both on the same server exporting the same directories is common and entirely fine; NFS for the Linux boxes, Samba for everything else.

Performance-wise, NFS typically leads between Linux machines, most noticeably on workloads with many small files, while large sequential streams over SMB3 come close enough that convenience should usually win the argument.

Mounting at boot without breaking boot

Network shares in /etc/fstab have a failure mode: the server is down, and your client hangs at boot waiting for it. The modern options prevent that:

nas:/srv/media  /mnt/media  nfs   defaults,nofail,x-systemd.automount,_netdev  0  0
//nas/media     /mnt/media  cifs  credentials=/etc/samba/creds,uid=1000,nofail,x-systemd.automount  0  0

nofail lets boot proceed without the share; x-systemd.automount defers mounting until first access, which also transparently reconnects after server reboots. For cifs, a credentials file keeps the password out of the world-readable fstab (chmod 600 /etc/samba/creds).

The security boundary

Neither protocol is internet-facing technology. NFS’s IP-based trust is meaningless across the internet, and exposed SMB has been the entry point for some of the most damaging worms ever written. Both belong on the LAN, and remote access belongs to a VPN layer like WireGuard, after which the shares work exactly as if you were home. For syncing files across the internet without a VPN, that is not a job for either of these; purpose-built tools like Syncthing or Nextcloud are the right answer at that layer.

Frequently Asked Questions

What is the difference between NFS and Samba?

NFS is the native Unix network filesystem, fast and simple between Linux machines, with trust traditionally based on client IPs and matching user IDs. Samba implements the SMB protocol from the Windows world, with username and password authentication and universal client support.

Which is faster, NFS or Samba?

Between Linux machines on a trusted network, NFS usually wins on throughput and latency, especially for many small files. Modern SMB3 has narrowed the gap considerably, and for large sequential transfers the difference is often minor.

Can Windows or macOS access an NFS share?

Windows has an optional NFS client and macOS can mount NFS, but the experience is second-class on both. For mixed-OS environments Samba is the pragmatic choice since every OS speaks SMB natively.

Why do file owners look wrong on my NFS mount?

Classic NFSv3 maps users by numeric UID, so UID 1000 on the client is whoever UID 1000 is on the server. Keep UIDs consistent across machines or use NFSv4 with idmapd configured for name-based mapping.

How do I make a network share mount automatically at boot?

Add it to /etc/fstab, preferably with the nofail and x-systemd.automount options, so boot does not hang when the server is unreachable and the share mounts on first access.

Is it safe to expose NFS or Samba to the internet?

No, neither is designed for internet exposure. Keep both on the LAN or reach them across a VPN such as WireGuard. For internet file sync, purpose-built tools like Syncthing or Nextcloud are the right layer.