NFS vs SMB for Proxmox and Docker: Which Should You Use?

FTC disclosure: This article contains affiliate links. If you purchase through these links, we may earn a commission at no additional cost to you.

Key Takeaways

If your workload is mostly Linux-to-Linux - Proxmox backups, VM templates, Docker media mounts, app data, and backup targets - NFS usually wins on simplicity and raw efficiency.
If Windows or macOS users need to browse, edit, or map the same share directly, SMB is the safer default because the permissions model and client support are better.
Real-world comparison data is pretty consistent: NFS tends to pull ahead on Linux small-file work, while SMB gives up some performance in exchange for better cross-platform behavior and easier authentication.
For most homelabs, the smartest answer is not choosing one protocol for everything. It is using NFS for infrastructure storage and SMB for people-facing file shares.
If you actually need block storage for clustered hypervisors or very specific database workloads, stop forcing this decision and look at iSCSI instead. We already covered that in our broader NFS vs SMB vs iSCSI guide.

NFS or SMB? If you are running Proxmox and Docker in the same homelab, that question matters more than most people admit.

I spent time comparing benchmark data from multiple homelab-focused tests, vendor documentation, and real deployment patterns across Proxmox and Docker hosts. The short version is simple: NFS is usually the better infrastructure protocol, SMB is usually the better household file-sharing protocol, and trying to make one protocol do both jobs is where most of the pain starts.

This is not a theoretical protocol-history piece. I am going to answer the version that actually matters when you have a NAS, a Proxmox node or two, a Docker host, and limited patience.

Recommended gear for fast network shares

If you are tuning network storage for Proxmox or Docker, these are the upgrades that move the needle the most:

Those are not magic fixes, but better networking and a sane NAS platform make protocol testing a lot less noisy.

My testing methodology for this comparison

I did not invent benchmark numbers for this article. I based the comparison on a mix of:

real homelab benchmark writeups from Joe Plaa and DiyMediaServer
structured comparison data from HomeLab Starter and StarWind
official documentation from Proxmox, Microsoft, and Red Hat on how each protocol behaves and where it fits

The data points I leaned on most were these:

DiyMediaServer found NFS roughly 25 to 30 percent faster than SMB for Linux small-file activity, with a practical example of a 20-minute Jellyfin scan dropping to about 14 minutes over NFS.
Joe Plaa's TrueNAS-based lab testing found NFS hit about 125 MB/s on large-file workloads with the lowest CPU utilization among the compared share types, while SMB remained workable but lagged on reads.
HomeLab Starter's 10GbE directional ranges put NFS sequential reads around 800 to 1000 MB/s and SMB around 700 to 900 MB/s on SSD-backed storage.

That is enough to answer the homelab question honestly: you are not choosing between a good protocol and a bad one. You are choosing between a Linux-first file-sharing protocol and a compatibility-first file-sharing protocol.

The short answer

If you run mostly Linux infrastructure, pick NFS.

If humans with Windows laptops are going to touch the share every day, pick SMB.

If both are true, export both protocols from the NAS - but do not make the same writable dataset the center of your whole life without thinking through ownership, permissions, and application behavior first.

NFS vs SMB at a glance

Category	NFS	SMB
Best fit	Proxmox storage, Linux backup targets, Docker host mounts	Mixed OS file sharing, Windows clients, team or family shares
Linux performance	Usually better	Usually a bit slower
Windows support	Weak to awkward	Excellent
Permissions model	UID/GID based, simple when Linux hosts agree	Richer auth and ACLs, better for mixed clients
Encryption	Possible, but more effort	Easier with SMB3
Setup pain	Lower for Linux-only labs	Lower for mixed-client homes
My verdict	Best for infrastructure	Best for user-facing shares

What actually changes in Proxmox and Docker

This is where a lot of articles get lazy. They tell you NFS is “for Linux” and SMB is “for Windows” and then call it a day. That does not help if your actual question is, “What should I mount on my Proxmox node?” or “What should I bind into my Docker containers?”

In Proxmox

NFS is usually the cleaner fit for:

ISO storage
backup targets
templates
general shared storage for Linux-heavy environments

Why? Because Proxmox already lives in a Linux world. NFS matches that model well, stays simple, and does not fight you on credentials the way SMB sometimes does. If you have already read our Proxmox Storage Architecture guide, this lines up with the same principle: keep infrastructure storage boring.

SMB can still work in Proxmox, especially if your NAS is already serving household files over SMB and you want fewer protocols to maintain. But it is rarely the cleanest answer for hypervisor-side storage unless the rest of your environment is heavily Windows-oriented.

In Docker

For Docker, NFS is often the better host-level mount when:

your Docker host is Linux
the data is mostly media, backups, or app content
you want one clean mount on the host and then bind-mount it into containers

That pattern is usually simpler than trying to deal with CIFS quirks inside containers. It also lines up well with how people already structure Linux host mounts for media servers and backup jobs.

SMB becomes more attractive when the same share also needs to be browsed directly from Windows or macOS devices. If family members, editors, or other humans need direct mapped-drive access, SMB earns its keep fast.

If you are still sorting out the network side, our Docker Networking Deep Dive is worth reading next because bad network design makes both protocols look worse than they are.

Performance: where NFS actually wins

The performance story is not “NFS destroys SMB in every case.” It is narrower than that, which is good news because it makes the decision easier.

Small files and metadata-heavy workloads

This is the most important difference for many Linux homelabs.

DiyMediaServer's testing is useful here because it focuses on the kind of workload people actually feel - library scans, metadata churn, and lots of little reads rather than one giant movie copy. Their conclusion was that NFS on Linux clients was about 25 to 30 percent faster for small-file activity. That is enough to be noticeable, not just benchmark-forum noticeable.

If your stack includes Plex, Jellyfin, Sonarr, Radarr, Immich, or backup jobs that chew through directories full of small files, NFS usually feels snappier.

Large sequential reads and writes

For bulk media streaming or large file moves, the gap shrinks.

Joe Plaa's lab results found NFS leading large-file throughput at around 125 MB/s with the lowest CPU utilization in the final comparison. DiyMediaServer also noted that for large sequential reads, NFS and SMB were often within a few percent on 1GbE.

That matches what I usually tell people: if your only metric is “can it stream a 4K remux over a gigabit LAN,” both protocols are probably fine.

CPU overhead and efficiency

This is the part people skip because it is less visible than transfer speed screenshots.

If one protocol gets similar throughput while using less CPU on the host, that matters on smaller NAS boxes and mini PCs. Joe Plaa's writeup favored NFS here for big-file workloads. On low-power hardware, that efficiency advantage is worth caring about.

My verdict on speed

If the client and server are both Linux, NFS is the performance winner often enough that I would treat it as the default.

If your clients are mixed and convenience matters more than squeezing the last bit of Linux efficiency out of the link, SMB is fast enough to justify its overhead.

Permissions and reliability: where SMB earns its spot

NFS's simplicity is great right up until your UID and GID mapping gets messy.

In a pure Linux lab, that is usually manageable. In a mixed environment, it becomes one more background problem waiting to turn into “why is this container writing files nobody else can edit?”

SMB is heavier, but it is also friendlier when you need:

Windows-native access
user-level authentication
better integration with existing household or office habits
easier per-user permissions across mixed devices

SMB3 also gives you built-in encryption and a more modern security posture than old NFS defaults. Microsoft documents SMB 3.x features well, and if you are exposing shares across trusted but shared internal networks, that matters.

The catch is that SMB's flexibility comes with more knobs. More knobs means more ways to misconfigure it.

Security differences that actually matter

Both protocols are fine inside a trusted LAN if you set them up correctly. Both are bad ideas to expose directly to the internet.

Choose NFS when security looks like this

Linux-only clients
tight subnet restrictions
controlled UID/GID mappings
no need for direct Windows client access

If you go NFS, prefer NFSv4 and use root_squash unless you have a very specific reason not to. Red Hat's NFS guidance is still a good reference on export behavior and hardening.

Choose SMB when security looks like this

multiple human users
Windows clients everywhere
stronger per-user auth requirements
you want easier encryption with SMB3

If you go SMB, disable SMB1 completely. No excuses. SMB1 deserves to stay dead.

The comparison most people actually need

Scenario 1: Proxmox backups, ISOs, and templates

Winner: NFS

NFS is the better fit for most Proxmox storage jobs because the environment is already Linux-native, the setup is straightforward, and the performance profile is usually better for infrastructure workloads.

If you are trying to keep your hypervisor boring - and you should - NFS is the call.

Scenario 2: Docker media mounts and app data on a Linux host

Winner: NFS

Host-mount the NFS share, then bind it into containers. That keeps the storage setup centralized on the host and avoids extra weirdness. This is especially true for media stacks and read-heavy application data.

Scenario 3: Household file shares used by Windows and macOS devices

Winner: SMB

This is why SMB exists. If actual humans are mapping drives, dragging files around, and expecting the same folder to behave sanely from multiple operating systems, SMB is worth the trade.

Scenario 4: One NAS serving both infrastructure and people

Winner: both, but with boundaries

This is the realistic homelab answer.

Run NFS exports for Linux infrastructure. Run SMB shares for people-facing access. Keep the purpose of each share clear. Do not turn one random all-purpose share into the dependency point for Proxmox, Docker, Windows clients, backups, and a half-finished media workflow all at once.

That architecture looks slightly less “clean” on paper, but it is much cleaner when you are the one fixing it at 11 PM.

Pros and cons

NFS pros

Faster on Linux in many real homelab workloads
Lower overhead for Proxmox and Docker use cases
Simple to mount and automate on Linux hosts
Usually easier to reason about in an infrastructure-only environment

NFS cons

Weak fit for Windows-heavy access
UID/GID mismatches can get annoying fast
Stronger security setups take more work than many people expect
Less friendly when non-technical users need access

SMB pros

Best compatibility across Windows, macOS, and Linux
Better user-facing authentication and ACL behavior
SMB3 encryption is easier to adopt
Good default for shared household or team storage

SMB cons

More overhead in Linux-to-Linux scenarios
Often slower on small-file activity
More configuration surface area
Easy to keep “working” while still being messier than it needs to be

Who should pick NFS

Pick NFS if you are one of these people:

you run Proxmox and want a clean NAS target for backups, templates, or ISO storage
your Docker host is Linux and the mounted data is mostly media, backups, or app content
your clients are mostly Linux systems, LXCs, or hypervisor hosts
you care more about low-friction infrastructure storage than friendly desktop browsing

Who should pick SMB

Pick SMB if you are one of these people:

Windows devices touch the share every day
your family or team expects mapped drives and simple credentials
you need richer per-user access control
you care more about client compatibility than shaving a bit of protocol overhead

My winner

For Proxmox and Docker specifically, NFS is the winner.

The data points that matter most all lean the same way: better Linux efficiency, better small-file behavior, simpler integration with Linux infrastructure, and less friction for the kinds of mounts homelabbers actually use under Proxmox and Docker.

That said, SMB is not the loser in the broader homelab. It just wins a different category.

If I were building one typical homelab NAS today, my policy would be:

NFS for infrastructure storage
SMB for user-facing file shares
iSCSI only when I truly need block storage

That split avoids a lot of bad compromises.

Build the rest of the storage stack around the protocol choice

Protocol choice is not the whole design.

If you pick NFS or SMB but ignore the rest of the stack, you can still end up with slow or brittle storage. A few related reads on the site are worth opening next:

TrueNAS Scale vs Core vs Unraid if you are still deciding what should serve the share in the first place
Best NVMe SSD for NAS Cache in 2026 if you are trying to improve metadata-heavy workloads
NAS Backup Strategies because a faster share is still not a backup
Proxmox LXC vs VM if you are still working out what should live on top of the storage

Official docs worth bookmarking

FAQ

Is NFS faster than SMB for Proxmox?

Usually, yes. In Linux-heavy environments, NFS tends to be the cleaner and faster choice for shared storage, backups, templates, and other Proxmox-adjacent workloads. It is not magic, but it usually involves less protocol overhead and fewer compatibility layers.

Is SMB okay for Docker volumes?

It can work, but I usually prefer mounting NFS on the Linux host and then bind-mounting it into containers. SMB becomes more attractive when the same share also needs direct access from Windows or macOS users.

Should I use one protocol everywhere in my homelab?

Probably not. Most homelabs are better off using NFS for Linux infrastructure and SMB for people-facing shares. One protocol for everything sounds elegant until permissions and client behavior start fighting each other.

What about iSCSI?

Use iSCSI when you need block storage, not just shared files. It is better thought of as a different category than a direct replacement for NFS or SMB. For the broad three-way decision, read our full NFS vs SMB vs iSCSI comparison.

Does a faster protocol matter on 1GbE?

Yes, but not always dramatically for large media files. The biggest differences usually show up in small-file operations, metadata-heavy scans, and Linux-to-Linux workloads. On plain 1GbE, both can still stream large files fine if the storage backend is competent.

Final verdict

If the share exists to serve Proxmox and Docker, pick NFS first and only talk yourself out of it if you have a real compatibility reason.

If the share exists to serve people, pick SMB first and only talk yourself out of it if the environment is overwhelmingly Linux and you want the extra efficiency.

That is the answer I would use in a real homelab, not just in a clean-room comparison chart.