You're Mounting It Wrong: The NFS Mistake That Breaks Homelabs
The confusion: “why can’t my VM just see my storage?”
It starts simple enough. You’ve got a Proxmox VM with limited storage, maybe 100GB, and a perfectly good NAS sitting there with terabytes of free space. The goal feels obvious: connect the two and move on.
Then you hit the wall. Where’s the path? Do you partition more space? Resize disks every time? Suddenly something that should feel plug-and-play turns into a maze of mounting, permissions, and conflicting advice.
That’s the first mistake: assuming NFS works like local storage. It doesn’t. With NFS, the work is exposing the storage correctly instead of resizing disks.
The first divide: VM vs LXC (and why it matters more than you think)
Almost immediately, the conversation splits into two camps depending on whether you’re using a VM or an LXC, because the answer changes everything.
For VMs, the advice is refreshingly boring: just mount the NFS share inside the VM using /etc/fstab and call it a day. One commenter put it plainly: “VM you just do through fstab… then mount -a.”
LXCs are where things get weird. Now you’re dealing with container boundaries, mount points, and permission mapping. The question grows from “connect to storage” into “how do I safely pass storage through layers of abstraction?”, and that’s where most setups start to fall apart.
The clean approach: mount on the host, then pass it down
One of the most consistent recommendations cuts through the noise: don’t mount NFS inside the container. Mount it on the Proxmox host, then pass it into the LXC. It sounds like extra work, but it simplifies everything.
One user laid it out step by step: mount the NAS share to something like /mnt/proxmox_nfs on the host, then add a mount point in the LXC config so the container can access it.
This approach does two things:
- Keeps networking and storage logic centralized
- Avoids weird container permission issues
It’s not flashy, but it works consistently, and in homelabs, consistency usually beats cleverness.
The permission nightmare: “why can Plex see it but nothing else can?”
This is where things really break. You mount the share, it shows up, and Plex can read it. Your other apps get nothing: no access and no errors, just silence.
That’s because of user permissions inside containers. One frustrated comment captured it perfectly: one LXC can access the NAS, but others “use a root user that can’t access” it, even with bind mounts.
Nobody tells you this upfront: mounting is easy, and permissions are the hard part. You’re dealing with UID/GID mismatches between:
- The NAS
- The Proxmox host
- The container users
If those don’t align, access breaks even when everything looks correct.
The security debate: privileged vs unprivileged containers
Then comes the argument that never really gets resolved.
Some people say to just use privileged containers, because they’re easier, there’s less friction, and everything works. Others push back hard: “Privileged LXC is a terrible idea.” They’re not wrong.
Privileged containers blur the isolation boundary. They make mounting easier, but at the cost of security. Unprivileged containers, on the other hand, are safer but require more setup, especially around permissions.
One user defends unprivileged LXCs strongly, arguing they’re “safe af” if configured correctly and avoid the headaches of VMs for things like GPU sharing.
So now you’re choosing again, between convenience and isolation.
The architecture split: one container vs many
Just when you think you’ve figured it out, another debate appears: do you run everything in one container, or split services across multiple LXCs?
Some argue for separation, with one container per app, which is cleaner, safer, and easier to manage long-term. Others prefer grouping services together to simplify networking and VPN setups.
One take sums it up nicely: separate containers are easier overall, but combining them can make sense depending on your workflow. There’s no single right answer, just tradeoffs.
The reality check: NFS isn’t the hard part
NFS itself is actually simple. You define a share, mount it, and you’re done. As one commenter pointed out, it’s basically just:
IP:/path/to/share → /mnt/path
The complexity comes from everything around it:
- Where you mount it (host vs VM vs LXC)
- How you expose it (bind mounts, config files)
- Who can access it (permissions, user mapping)
That’s why it feels harder than it should. Mounting storage is the easy bit; integrating the systems around it is the work.
The takeaway: stop fighting the wrong layer
If there’s one lesson here, it’s that most people struggle with NFS because they’re solving the wrong problem. They try to:
- Resize VM disks instead of using network storage
- Mount directly inside containers instead of using the host
- Ignore permissions until everything breaks
The smoother path is almost always:
- Mount NFS on the Proxmox host
- Pass it into LXCs with mount points
- Fix permissions properly
It’s not the quickest route, but it won’t come back to bite you later. In a homelab, that’s the difference between something that works today and something that still works next month.