File Transfer Protocols: Part 4 — SMB or NFS

When you need to work with files directly on the server — open documents, save projects, keep shared departmental folders — you use network file system protocols. There are two: SMB, familiar to Windows users, and NFS, the Unix and Linux world standard. Both let you mount a folder on a server as if it were a local drive, but they’re designed differently.

SMB: Windows file shares

SMB (Server Message Block) is the protocol for Windows shared folders and printers. If you mounted a network drive \\server\share, you used SMB. It runs over TCP, port 445.

SMB versions

• SMB1 (its dialect is also called CIFS) — an obsolete version with known vulnerabilities that ransomware exploited. Microsoft declared it deprecated in 2014.
• SMB2 and SMB3 — modern versions. SMB 3.x supports traffic encryption, multiple channels simultaneously (multichannel), and protection against downgrade during connection negotiation (SMB 3.1.1).

According to Microsoft documentation, starting with Windows 10 and Windows Server version 1709 SMB1 is not installed by default, and on Windows 11 after a clean install there is neither an SMB1 client nor server. In practice this means a legacy NAS or MFP that only speaks SMB1 simply won’t be seen by modern Windows. Microsoft strongly advises against re-enabling SMB1 — the right solution in this case is to update the device firmware or replace the device.

You can check and enable encryption on a Windows server in PowerShell:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EncryptData
Set-SmbServerConfiguration -EncryptData $true

Samba: SMB server on Linux

Samba is a free (open-source) implementation of SMB. With it, a Linux server can serve folders to Windows and macOS clients, and also connect to Windows resources. By default modern Samba accepts connections no lower than SMB 2.02 (server min protocol = SMB2_02) — so SMB1 is disabled here too.

Minimal shared folder for a department:

# /etc/samba/smb.conf
[global]
   server min protocol = SMB2_02
   server smb encrypt = desired

[docs]
   path = /srv/share/docs
   valid users = @office
   read only = no
   create mask = 0660
   directory mask = 0770

sudo smbpasswd -a ivanov       # Samba password for the system user
testparm                        # check the configuration
sudo systemctl restart smbd

• valid users = @office allows only members of the office group.
• read only defaults to yes — to allow writing you must explicitly disable it.
• server smb encrypt = desired offers encryption to clients but does not require it; required will require encryption from all clients, and old devices won’t be able to connect.

Mounting from a Linux client:

sudo mount -t cifs //192.0.2.20/docs /mnt/docs -o username=ivanov,vers=3.1.1

NFS: Network File System for Unix

NFS (Network File System) was originally created for Unix. Its natural environment is Linux servers, virtualization clusters, and storage for containers and backups.

NFS versions

• NFSv3 — simple and fast, but requires several services and ports (rpcbind on 111, mountd and others), which complicates the firewall. Access is determined by the client’s address, and the user is identified by the numeric UID that the client supplies.
• NFSv4.x — works over a single port 2049, supports Kerberos and maps users by names rather than just numbers. It’s the preferred choice for new installations.

The main pitfall of NFS: who the server trusts

By default NFS uses the sec=sys mode: the server trusts the UID and GID provided by the client. If a user has UID 1000 on the client, the server will consider them the owner of files with UID 1000 — even if that’s a different person on the server. Hence two rules:

1. Export only to trusted addresses, not the whole network.
2. Where clients cannot be trusted, use Kerberos: sec=krb5 (authentication only), krb5i (plus integrity), krb5p (plus privacy/encryption).

The root user on the client is mapped to an anonymous user by default (root_squash) — this is protection and should not be disabled without a good reason.

Minimal NFS server configuration

# /etc/exports
/srv/backup  192.0.2.0/24(rw,sync,no_subtree_check)

sudo exportfs -ra           # apply changes
sudo exportfs -v            # check what's exported
# on the client
sudo mount -t nfs4 192.0.2.30:/srv/backup /mnt/backup

According to the exports documentation: ro is the default, so you need rw for write access; sync acknowledges to the client only after the data is written to disk; async is faster, but data can be lost if the server crashes.

What actually affects speed

Debates about “which is faster — SMB or NFS” usually come down not to the protocol but to the environment:

• Network. A gigabit network limits speed to roughly 110 MB/s in either protocol. Moving to 10 Gb/s gives more benefit than swapping protocols.
• Disks. If the server has a slow array, a faster protocol won’t help.
• Small files. Thousands of small files hit metadata operation latency, not throughput.
• Synchronous writes. sync in NFS and encryption in SMB slow down writes — that’s the price of reliability and security.
• Parallelism. SMB 3 supports multichannel; in the Linux NFS client there is a mount option nconnect for multiple TCP connections.

What to choose

Common mistakes

• Re-enabling SMB1 for an old MFP. This exposes the network to vulnerabilities exploited by ransomware. It’s better to scan to a folder over SMB2 after updating the device firmware or use another mechanism.
• Port 445 or 2049 open to the internet. Network file systems are intended for a trusted network.
• NFS export to the whole subnet with no_root_squash. Any root on any client gets root privileges on the exported files.
• Different UIDs on NFSv3 clients. Files “change owner” depending on which machine you view them from.