Proxmox privileged LXCs looked harmless, and that's exactly why my security fell apart

Published Aug 25, 2026, 9:00 AM EDT Ayush Pande is a PC hardware and gaming writer. When he's not working on a new article, you can find him with his head stuck inside a PC or tinkering with a server operating system. Besides computing, his interests include spending hours in long RPGs, yelling at his friends in co-op games, and practicing guitar. Proxmox packs dozens of neat features that make it extremely useful for home lab setups, and its support for Linux Containers deserves a special shout-out. Thanks to their lightweight design, you can use LXCs to host all sorts of cool services and projects instead of allocating extra system resources to bulky virtual machines. Combine that with the self-hosting-centric packages on the Proxmox VE Helper Scripts repo, and you can use LXCs to build an army of FOSS tools even on cheap, computationally-challenged systems. But regardless of the method you may use to deploy LXCs, you may have noticed a toggle that mentions privileged containers – one that remains off by default. And as my fledgling self realized years ago at the beginning of my home lab journey, there’s a good reason why the general consensus is to avoid them as much as possible. That’s what makes them attractive when you’re new to Proxmox Before I discuss why most tinkerers avoid privileged LXCs like the plague, let me go over their design. The root user (with the UID 0) within these LXCs maps to the same root account on the underlying host, thereby granting them unrestricted access to certain devices and services (and hence earning them the “privileged” moniker) . On the contrary, unprivileged LXCs have their root user as a high-numbered account on the host, one with significantly fewer permissions. As such, privileged LXCs might seem better than their unprivileged counterparts for certain server projects and self-hosted services. If you want to let an LXC access an SMB or NFS share, privileged containers work well with them without requiring additional tweaks. Let’s say you’ve got all your painstakingly-ripped movies and TV shows on a NAS, and you want to use them with a Jellyfin LXC on your PVE node. Going with an unprivileged LXC in this situation would require a couple of workarounds when you pair it with the network shares, as you can’t directly mount network shares on these containers due to UID/GID mismatch shenanigans. So, you might be tempted to switch to a privileged LXC, as it can pair with network shares directly once you run the correct mounting command for your NFS/SMB share. As much as I hate to admit, that’s pretty much what I did for my first Proxmox-powered Jellyfin server, and it took me a few weeks to realize the security implications of this blunder. But they can easily compromise the security of your entire Proxmox node And it’s all due to the way they handle privileges Interestingly enough, privileged LXCs are a threat to home labs precisely for the same reason why they mesh well with network shares. Since the root user on these LXCs is the same as the one on your PVE host, any attack that manages to breach past their security measures can cause the entire node to become infected. After all, once the attacker compromises the LXC, the root-level privileges make it really easy for them to escape the confines of the containerized environment and start affecting the underlying node (and by extension, the rest of your virtual guest arsenal). Unprivileged LXCs, on the other hand, have nowhere near the same level of permissions as their privileged brethren. So, if they do get compromised in a malware attack, the chances of it escaping the environment and propagating to the underlying node are fairly low. Of course, that’s not to say it’s impossible, as certain types of malware have host takeover capabilities and can break out of the container. That said, your host is a lot less vulnerable with unprivileged LXCs, and it’s why I recommend opting for them instead of going with privileged containers. Fortunately, it’s still possible to enable SMB and NFS shares for unprivileged containers on Proxmox using the bind mount workaround, and it’s what I use for my Jellyfin, Kavita, and other LXCs that require network shares. If you’re following along, you’ll have to mount the network share on your Proxmox host via the Storage tab under the Datacenter section. Then, you’ll need to switch to the LXC that you want to pair with your NAS’ storage provisions and create a new folder where you want the SMB/NFS share to exist on the container. With that, you’ll want to head to the Shell tab on your PVE host. Finally, you can run pct set CID -mp0 /mnt/share,mp=/mnt/container-path to make the network share accessible inside the container. For reference, CID is the container ID, /share is the name of the SMB/NFS share mounted on your host, and /container-path is the new directory you’d created earlier. Privileged LXCs may sound useful, but they’re not worth it in the long run Although I’ve stopped using privileged LXCs altogether, I still rely on unprivileged containers for most of my self-hosted apps, especially for services running on PVE nodes I’ve recycled from outdated hardware. And for projects where I want even more isolation, I tend to go for my trusty dev VMs, which I’ve locked down behind hardened firewall rules. Proxmox