I used to think choosing between NFS and SMB was like picking between Coke and Pepsi: pure personal preference with no real consequences. Turns out I was wrong. If you’re running a Linux media server and care about performance, compatibility, and maintaining file permissions. The protocol you choose will define your entire experience.

This guide cuts through the mythology and gives you a practical decision framework for NFS vs SMB. I’ll show you where each protocol shines, how to set these up on a Linux server, what settings matter, and how to dodge the gotchas that regularly bite home labs. Whether running a mixed-OS environment or trying to access your Unraid shares from Windows, this one’s for you.

UGREEN NASync DXP4800 Plus 4-Bay Desktop NAS This 4-bay NAS is perfect for experimenting with NFS and SMB protocols, letting you easily set up and compare file sharing for your media server. Its Intel N100 CPU and 2.5GbE port ensure fast, reliable transfers, ideal for your new or existing homelab.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

NFS vs SMB Basics: What They Are and Why You Should Care

Network File System (NFS) is the native file-sharing protocol for Unix and Linux systems. It makes remote folders appear as local directories, with tight integration into the Linux kernel. Think of it as Linux’s preferred way to share files across a network.

Server Message Block (SMB) is Windows’ native file-sharing protocol. Linux systems access SMB shares through Samba, while macOS speaks SMB natively. SMB packs more features and integrates deeply with Windows authentication and permissions.

Why this matters for your media server:

Your media server constantly reads metadata, generates thumbnails, and streams video files. The protocol you choose directly impacts how fast your library scans complete, how quickly your media player interfaces load, and whether file permissions stay manageable.

Your client’s operating systems drive the decision. Running a Linux media server accessed only by other Linux machines? NFS typically performs better. Mixed environments with Windows, macOS, and Linux clients generally work better with SMB.

Security considerations differ between protocols. Both can be properly secured on a trusted LAN, but their default configurations and hardening approaches vary significantly. Poor defaults have real consequences: SMBv1 vulnerabilities can allow for major malware outbreaks, while misconfigured NFS exports can expose sensitive data by mistake.

Which One Should You Use? A Simple Decision Branch

• If all clients are Linux, Unix, or Android TV:   - Pick NFS. It’s fast, mature, and simple for Linux-to-Linux communication. You’ll avoid permission (UID/GID) mismatches. If you manage identities incorrectly.
• If you have Windows or macOS clients:   - Pick SMB. It’s native on Windows, works smoothly on macOS, and Samba on Linux is robust. Add NFS for Linux-only apps if needed.
• If security and centralized authentication matter:   - SMB3 with modern authentication and encryption is straightforward in Windows and Samba.   - NFSv4 with Kerberos can be secure too, but it’s more complex to set up. If you’re not doing Kerberos, restrict NFS to trusted subnets and use strong firewall rules.
• If you use Unraid or other NAS:   - Unraid and most NAS platforms support both protocols. Use SMB for Windows clients, NFS for Linux clients or Docker containers, and don’t expose either protocol externally.

Core Pros and Cons: What You Actually Feel Day to Day

NFS: Strengths and Weaknesses

Pros:

• Fast on Linux: The lower protocol overhead and native kernel modules on clients allow for performance when dealing with many small file operations in Linux-only environments. Making it ideal for Linux media servers where you’re streaming content to other Linux clients and managing large collections.
• Simple integration: NFS is part of the Linux ecosystem. Mounts, fstab, systemd units, and permissions make sense if you track UIDs and GIDs. No wrestling with foreign concepts.
• Stateless heritage: Classic NFSv3 is largely stateless, which can make some failure recoveries simple.

Cons:

• Security by default is weaker: Older NFS versions lack encryption and rely on client-side UID/GID trust. NFSv4 improves this and supports Kerberos, but few home labs set that up correctly. Most people live with the risk and secure it with firewall rules.
• Windows support is limited: Windows can mount NFS, but the built-in client is inconsistent across editions and awkward to configure for typical home use. If you need to access shares from Windows regularly, this becomes a real headache. Just use SMB in this case.
• Focused feature set: NFS is great at file and directory sharing, but lacks the broader Windows ecosystem features SMB provides. It does one thing well, but just that one thing.

Best fit: Linux media servers and clients, Docker workloads, Kubernetes, and Linux-only NAS access.

SMB: Strengths and Weaknesses

Pros:

• Cross-platform: Native on Windows, strong on macOS and Linux via Samba. Excellent for mixed-OS homes and offices. Whether you need to access NAS shares from Windows or macOS, SMB just works.
• Modern security: SMB3 supports strong authentication and optional encryption, integrates with Active Directory, and includes features like signing and multichannel. When configured properly, it’s genuinely secure.
• Feature-rich: Besides files, SMB supports printers and deep Access Control List (ACL) capabilities that align with Windows permission models. If you have a Windows background, the permissions make intuitive sense.

Cons:

• More overhead: Often slower than NFS in Linux-to-Linux scenarios with many small files, though SMB3 performance can be excellent with Windows clients. The extra features come at a performance cost.
• Complexity: More knobs to turn, especially in Samba. Easy to misconfigure permissions or lose performance with certain security defaults if you don’t plan for them. The flexibility is both a blessing and a curse.

Best fit: When you have a mixed OS environment, Windows clients, or macOS systems.

Preparing Your Server or NAS

Whether you’re running a Linux server, Unraid, or another NAS system, the setup approach stays consistent across platforms. Here’s what you need to sort out first:

• Decide which shares will be accessed by which clients
• Use SMB for Windows and macOS connections
• Use NFS for Linux apps and clients
• Avoid exporting the same path through both protocols unless you understand the consequences for permissions and extended attributes.
• Keep both protocols scoped to your trusted LAN. Never port-forward 445 or 2049 from your router to the internet.

On Unraid specifically:

SMB comes enabled by default, making Windows access straightforward. You can enable NFS per share for Linux clients and containers. Mapping Windows drives to SMB shares is point-and-click simple. However, accessing NFS shares from Windows requires client-side tools and sometimes Windows Enterprise features. For most home setups, SMB handles Windows clients just fine. Don’t add an unnecessary headache.

Setting Up SMB on a Linux Server (Samba)

Getting SMB running on Linux is straightforward once you know the steps. Here’s how to set up a proper media share that Windows, macOS, and other Linux machines can all access without drama.

Follow my SMB installation and Configuration Guide

Security Notes:

• Use SMBv3 or higher wherever possible. Disable SMBv1 entirely! It’s a security nightmare that should have died years ago.

The configuration above creates a secure, authenticated share that works reliably across different operating systems. Your Linux media server will play nicely with Windows clients, and you won’t have to deal with the permission headaches that sometimes plague mixed environments.

MINISFORUM MS-A2 With dual 2.5GbE and a 10GbE option, this mini PC is an outstanding Proxmox host for running NFS/SMB servers or clients in VMs or containers. Its powerful Ryzen CPU and triple NVMe support make it perfect for high-speed media streaming and protocol testing. It’s a compact powerhouse for any homelab builder.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Setting Up NFS on a Linux Server

Getting NFS running on your Linux media server is straightforward once you know the steps. Here’s how to get it configured properly:

Follow my NFS installation and Configuration Guide

Security Best Practices You Should Not Skip

Here’s the thing about network file sharing: convenience and security often pull in opposite directions. But a few smart choices upfront will save you from becoming internet famous (and not in a good way).

Keep it local. SMB and NFS belong on your trusted LAN only. Never expose ports 445 (SMB) or 2049 (NFS) to the internet. Block them at your router and firewall. This isn’t paranoia; it’s basic hygiene.

SMB security essentials:

• Disable SMBv1 entirely. It’s ancient, vulnerable, and has no place in modern networks. Use SMBv2 or SMBv3.
• Enable strong authentication and SMB encryption where your data sensitivity justifies the CPU overhead. Yes, encryption costs performance, but that’s a trade-off worth making for sensitive content.
• If you need centralized user management, integrate with existing directory services rather than managing local accounts.

NFS security essentials:

• Stick with NFSv4 over older versions.
• Restrict exports by IP or subnet. Use root_squash to prevent compromised clients from wreaking havoc with root privileges.
• Deploy host-based firewalls to allow only known clients. Defense in depth matters.

The backup reality check: Neither SMB nor NFS will save you from accidental deletion or ransomware. Keep offline or versioned backups of your important data. Your future self will thank you.

Performance Tuning Tips That Pay Off

Getting good performance from network shares isn’t rocket science, but a few targeted tweaks can make a noticeable difference. Here’s what actually moves the needle:

NFS:

• When dealing with large sequential reads (like streaming movies), the default settings are fine. If you’re dealing with many small files, look at actimeo (attribute cache timing) and consider noatime to reduce metadata writes.
• Use NFSv4.2 when available. It cuts down on port sprawl and handles flaky network connections better.
• You can bump up rsize/wsize, but test with your specific NIC and switch setup. Bigger buffers aren’t always better buffers.

SMB:

• Enable SMB multichannel on capable clients and servers. It bonds multiple NICs or network paths for better throughput and fault tolerance.
• Stick with SMB version 3.x. Legacy dialects and SMB1 are security nightmares you don’t need.
• Signing and encryption keep you safe. If you’re on a trusted LAN and performance is critical, you can be selective about signing, but benchmark before changing defaults.

Both protocols:

• Jumbo frames can help, but only if every network hop supports the same MTU. Overlook one switch or router, and you will actually hurt performance.
• Always test with tools like robocopy, fio, or dd to measure before and after. Gut feelings don’t count when it comes to network performance.

Seagate Barracuda 24TB Internal Hard Drive A reliable, high-capacity hard drive is essential for storing and serving large media libraries over NFS or SMB. With 24TB of space, you can fully utilize your NAS or server and see real-world protocol performance with big files. It’s a must-have for any serious media server build.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Common Pitfalls and How to Avoid Them

• Mixing NFS and SMB on the same share:   - Beyond the scope of this post, but Windows ACLs and POSIX permissions are like oil and water. Samba stores NT ACLs as extended attributes, but NFS clients may not preserve them as expected. If you must mix protocols, separate your write paths or designate one protocol for writes and keep the other read-only.

• UID/GID mismatches on NFS:   - Keep your user and group IDs consistent across all Linux clients. Use centralized identity management (LDAP/SSSD) or carefully align your /etc/passwd entries. Trust me, debugging permission issues caused by mismatched IDs is not how you want to spend your weekend.

• Assuming “NFS is insecure” or “SMB is slow”:   - NFSv4 with Kerberos is actually quite robust. SMB3 on modern stacks is both fast and secure. The real performance and security outcomes depend on your defaults and client mix, not the protocol itself.

• Turning on async writes blindly on NFS:   - Async writes can boost speed, but at the cost of data safety during crashes. Understand the trade-off before flipping that switch.

• Exposing shares directly to the internet:   - This is how you get popped. Period. Use VPNs for remote access and never direct port forwards for file shares.

Example Scenarios: What To Choose

Here’s how to pick the right protocol based on your actual setup:

All Linux home: Export media via NFSv4, mount on Jellyfin/Plex, and your Linux desktop. Keep UIDs aligned across systems. Optionally offer SMB read-only for occasional Windows use. This gives you the performance benefits of NFS where it matters most while keeping Windows in mind.

Windows family PCs, macOS laptop, Linux server NAS: Use SMB for everyone. Enable NFS only for Linux containers or hosts that specifically benefit from it. Keep permissions in one place through Samba. Fighting permission mismatches across protocols isn’t worth the headache when SMB works fine for mixed environments.

Unraid backing multiple Docker apps and a Windows gaming PC: Give containers NFS or bind mounts for speed. Export the same content over SMB to Windows, but consider separate paths or read-only mounts to avoid permission drift. This hybrid approach lets your containers maintain speed while keeping Windows happy; However, watch out for permission conflicts if both protocols write to the same files.

Troubleshooting: Fast Diagnostics and Fixes

When things go sideways (and they will), here’s how to get back on track quickly.

Connection refused or cannot mount:

• Check if your SMB and/or NFS services are running: systemctl status smbd nmbd for SMB or nfs-server for NFS.
• Verify firewall rules. SMB needs TCP 445, NFSv4 needs TCP 2049. If you’re stuck with NFSv3, rpcbind and mountd may need additional ports.
• Double-check your server IP and share names. Yes, typos happen to all of us (I’m sure you can find a few on this page).

Permission denied:

• SMB: Verify the user exists in both Linux and Samba, check smbpasswd, and validate share-level access controls.
• NFS: UID/GID mismatches are the usual suspect. Align user IDs between systems or configure idmapd for NFSv4. Also, make sure your export options aren’t accidentally read-only.

Slow file transfers:

• Check what protocol version you’re actually using. Force vers=3.0 for SMB or vers=4.2 for NFS and test again.
• Disable Wi-Fi power saving on clients and test over wired connections.
• For SMB, experiment with multichannel, signing, or encryption settings to understand the performance trade-offs. Just don’t disable security features on untrusted networks.
• For NFS, try different rsize/wsize values and check for duplicate mounts or DNS slowness.

Windows cannot access NFS:

• Client for NFS might be missing or unsupported in your Windows edition. Stick with SMB for Windows clients and save NFS for Linux systems.

Media server doesn’t see new files immediately:

• SMB: Samba uses change notifications, but some applications still cache directory listings. Try a manual library refresh or verify your app is watching the correct path.
• NFS: Attribute caching can delay file visibility. Adjust actimeo or use sync where needed, but expect a performance hit.

Library scans crawl along:

• For many small files, NFS on Linux clients often outperforms SMB. Consider running your media scanner on a Linux machine over NFS, even if end users stream via SMB.

FAQs:

Conclusion: Make the Choice That Fits Your Clients and Your Risk

The decision comes down to matching your protocol to your environment and accepting the trade-offs:

• If your world is Linux, NFS is the pragmatic, fast, and simple default. It speaks the same language as your filesystem and won’t fight you on permissions.
• If you have Windows or macOS clients, SMB is the native choice that works. SMB3 brings solid security without the configuration headaches.
• You can run both protocols, but don’t blindly export the same writeable path over both unless you understand how permissions and metadata will clash between them.
• Lock it down: keep shares on your LAN, disable SMBv1 (seriously, it’s 2024), prefer NFSv4, and consider Kerberos or SMB encryption where your paranoia level demands it.

Next steps:

• Pick one protocol per client type and start simple. Don’t overcomplicate your first setup.
• Benchmark your scans and streams to establish a baseline.
• Layer on security and performance tuning only after you have a stable foundation.

Whether running a Linux media server or trying to access Unraid share from Windows, the protocol choice matters less than understanding what you’re choosing and why. Your media server will feel faster, safer, and more predictable when you stop treating network protocols like a coin flip and start matching them to your actual needs.

TP-Link 2.5GB PCIe Network Card (TX201) Unlocking multi-gig speeds is crucial for testing NFS vs SMB performance, especially with large media files. This affordable PCIe card ensures your server or client can handle high-throughput transfers, making protocol comparisons meaningful. It’s plug-and-play for most OSes, so you can focus on your homelab experiments.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon