A Network Attached Storage (NAS) device can hold your files centrally, including a NAS built on a Raspberry Pi. A Direct Attached Storage (DAS) device can also be shared by its connected computer. NFS and SMB determine how other machines access those shared files; they do not change the disks into a different kind of storage.
For a home setup, begin with the clients and permissions you need, then test the actual workload. There is no universal rule that NFS is faster or that an SMB share is automatically encrypted. This guide compares the choices and walks through checking a Linux mount before making it persistent.
What Are NFS and SMB?
NFS, Network File System, exposes server directories as exports that clients can mount. It is common in Linux and Unix environments. SMB, Server Message Block, exposes named shares and is widely used by Windows clients, with support on macOS and Linux as well. Samba provides SMB services on many Linux-based storage appliances.
Both let programs work with remote files through familiar paths. The network, server availability, identity mapping and locking still matter underneath. A mounted share can look like a local folder while responding very differently when the NAS restarts or the client loses connectivity.
Choose for Your Household and Applications
| Home scenario | Starting choice | Check before committing |
|---|---|---|
| Windows and Mac users sharing documents | SMB, with named accounts and household groups | Login, read/write access and denied access for an unauthorized account |
| Linux host reading a media library | NFS or SMB, according to the application's supported storage | Access as the service user and playback of your real files |
| Virtualization storage | The protocol and settings supported by the hypervisor and NAS | Its documented locking, availability and storage requirements |
| Application database or container data | Follow the application's storage documentation | Whether remote filesystems are supported for that particular directory |
A media application may support a remote library while requiring its database on local storage. Do not treat a successful file copy as approval to move every application's working data onto the NAS. Likewise, a television or phone needs an application that supports the chosen protocol; support is not guaranteed merely because the device can connect to Wi-Fi.
Permissions and Security Are Configuration Choices
With common NFS AUTH_SYS setups, the server relies on client-supplied user and group identities and export restrictions. Matching account names alone does not ensure numeric user IDs match. Restrict which clients can reach the export, and keep root_squash where appropriate; disabling it to fix a permission error gives client root much greater authority.
NFS can also use Kerberos: krb5 provides authentication, krb5i adds integrity protection and krb5p adds privacy. Those features need a properly configured identity environment. NFSv3 should not be described as inherently incapable of authenticated or encrypted operation. The Red Hat NFS security guide explains these distinctions.
SMB commonly authenticates a named user, with access governed by share permissions and filesystem permissions or ACLs. Signing protects message integrity; encryption protects the content in transit. They are different capabilities. Whether either is required depends on the server, client and policy, rather than the share's name or the presence of a password. Verify the negotiated settings; see Microsoft's SMB security documentation.
Neither protocol belongs on an unrestricted internet-facing port forward in this home example. Use a suitable private-access method for remote users and keep the NAS patched. Separate read-only family viewing from accounts allowed to modify or delete files. A backup account may also need a different policy from everyday users.
Protocol Versions and Performance
| Item | NFS | SMB |
|---|---|---|
| Versions | NFSv3 and NFSv4 variants differ in state and supporting services. | Modern SMB2/SMB3 differs substantially from obsolete SMB1. |
| Common network requirements | NFSv4 file traffic normally uses TCP 2049; NFSv3 commonly needs additional RPC services and ports. | Direct SMB over TCP normally uses port 445. |
| Access model | Export policy plus the configured identity/security mechanism | Authenticated account plus share/filesystem policy |
| Performance decision | Measure the supported configuration with your workload. | Measure the supported configuration with the same workload. |
Check your NAS and operating-system documentation for the complete firewall requirements rather than treating the common ports as an exhaustive list. Prefer a supported modern version and leave SMB1 disabled. The Linux driver and utilities still use names such as cifs and cifs-utils; those names do not mean a modern mount necessarily negotiates the obsolete SMB1 protocol.
The practical speed limit can be a disk, small-file metadata, CPU, encryption, Wi-Fi or a network link. Copying a large video and browsing thousands of small photos stress different parts of the system. Keep the same source files, client, connection and security policy when comparing protocols. Repeat the test and note whether cache effects could change the result; do not present one cached copy as a universal benchmark.
NFS nconnect can establish multiple TCP connections for a mount; that is not automatic multi-NIC bonding. NetApp's nconnect explanation describes its purpose and support requirements. SMB Multichannel is a separate feature with its own requirements, documented by Microsoft. Start with defaults and a working baseline before tuning connection counts.
Test a Linux Mount Before Editing fstab
The examples assume Debian or Ubuntu, sudo access and a NAS at 192.168.1.250. Its NFS export is shown as /mnt/tank/media and its SMB share as family_share. Replace those values with the exact client-facing paths in your NAS configuration. An NFSv4 pseudo-root can make the client export path different from the NAS's local directory.
Install only the clients you need and create separate empty mount points. Do not mount over a folder that already contains important local files:
sudo apt-get update
sudo apt-get install nfs-common cifs-utils
sudo mkdir -p /mnt/nas_media /mnt/nas_smbNFS Mount and Identity Check
Confirm the NAS export allows your client's address. This manual trial lets the client negotiate a supported NFS version; inspect the result before selecting a version for a permanent mount:
sudo mount -t nfs 192.168.1.250:/mnt/tank/media /mnt/nas_media
findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/nas_media
id
ls -ldn /mnt/nas_mediaCompare your numeric IDs with the server's ownership and policy. Test reading as your ordinary account, or as the actual service account that will consume the files. Running every test as root can hide the permission problem you need to solve. For a deliberately writable test folder, create and remove a uniquely named scratch file there, then verify its ownership on the NAS. Keep the export read-only if writing is unnecessary.
If access is denied, check the export path, client restriction, security flavor and filesystem permissions before changing ownership broadly. Do not fix it by disabling root squashing or granting everyone write access. The NFS mounting guide covers version selection and mount behavior.
SMB Mount and Credential Check
Create a NAS account with the intended share permissions. Store its credentials in a root-readable file rather than putting a password directly in a shell command or public fstab entry. The sequence below creates a new protected file; if that path already exists, inspect and edit it instead of overwriting its contents:
sudo install -d -m 0755 /etc/samba
sudo install -m 0600 /dev/null /etc/samba/nas-media.credentials
sudo nano /etc/samba/nas-media.credentialsEnter username= followed by the real NAS account name on one line, and password= followed by its password on the next. Add a domain line only if your authentication setup requires it. Keep the file private and include it appropriately in your protected configuration backup.
The shell variables below capture your current local account's IDs. They control local ownership presentation where the server does not supply it; they do not grant extra rights on the NAS:
task_uid=$(id -u)
task_gid=$(id -g)
sudo mount -t cifs //192.168.1.250/family_share /mnt/nas_smb \
-o credentials=/etc/samba/nas-media.credentials,vers=3.1.1,uid="$task_uid",gid="$task_gid"
findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/nas_smbThis trial requires SMB 3.1.1 support at both ends. If negotiation fails, inspect the NAS's supported versions and Linux client logs; do not fall back to SMB1. The account's server-side permissions still decide what it may access. If login succeeds but writing fails, compare the share policy and underlying filesystem ACLs. The Linux SMB client documentation explains credentials and local permission handling.
Make a Verified Mount Persistent
Back up /etc/fstab and keep a local recovery session available before editing it. For the tested NFS example, an optional systemd automount entry is:
192.168.1.250:/mnt/tank/media /mnt/nas_media nfs rw,_netdev,nofail,x-systemd.automount,x-systemd.mount-timeout=30s 0 0It deliberately leaves version negotiation at its normal behavior rather than forcing NFSv4.2 on every NAS. Restrict the version or security flavor when your environment requires it, using settings verified in the manual trial.
For SMB, convert the working command's options into an entry using the same credential path and share. Replace the shell variables with the actual numeric IDs printed by id; fstab does not expand shell expressions. Add the same systemd automount options if appropriate. Do not assume every user has ID 1000.
After saving, run sudo systemctl daemon-reload, unmount the manual trial only when no application is using it, and start the matching automount unit; the NFS example's unit is mnt-nas_media.automount. Access the directory and verify the actual network filesystem with findmnt. Reboot during a maintenance window to test persistence.
_netdev identifies a network mount and nofail changes boot dependencies. Automount defers the mount until access; the timeout limits its initial mount attempt. None guarantees that later file operations never wait when a running server becomes unreachable. See systemd's mount documentation. Test a controlled unavailable-NAS case before relying on this behavior for an important application.
Avoid Empty Mount Points and Conflicting Access
If a network mount fails, its underlying local directory may still exist. An application can then write to the host's disk instead of the NAS. Check that the expected remote filesystem is mounted before starting a dependent service, and use its documented startup dependencies and failure handling. An existing directory alone is insufficient evidence.
Serving the same dataset through NFS and SMB is not a universal performance recommendation. Identity mapping, ACLs and cross-protocol locking need support from the NAS and its specific version. TrueNAS documents a supported mixed-protocol configuration, rather than simply enabling two unrelated shares. Use separate datasets or a single protocol when you do not need coordinated mixed access.
Conclusion
Choose the protocol your clients and applications support, verify permissions as the real user, and measure your own workload before tuning. A share makes files accessible; it does not replace backups. Keep a separate recoverable copy and test restoring a file, because deletion, compromised credentials and storage failure can affect files regardless of which protocol delivered them.
