r/Proxmox
Technique to mount shared storage in unprivileged LXC without disabling snapshots?
I apologize if this is a common question, but several hours of searching and reading hasn’t yielded a solution I’ve been able to implement properly. I’m new to Proxmox and have been away from Linux in general for about 15 years, so there’s a lot of learning involved in the process of setting up my home servers.
I have two Proxmox host machines and want to be able to share several drives/directories/etc. between various (mostly Debian-based) containers and VMs residing on both hosts. My storage setup is very much unfinished at the moment (currently using individual drives until I can repurpose storage from a previous server) and doesn’t make use of ZFS or any of the more advanced options. Bind mounts using the commonly-recommended “mp#:” line in the [container].conf file initially seemed to be the way to go, until I realized I wouldn’t be able to take snapshots of containers. I’m trying to find a solution that will auto-mount shared storage but still allow snapshots (of the containers themselves, the mounted shared storage does not need to be included).
The alternative method that I saw recommended in almost all discussions like this was to use a Samba share instead, so I currently have the following setup:
PVE 1: 512 GB M.2 SATA partitioned into the default BIOS, EFI, and LVM by Proxmox during installation, plus a 2 TB 2.5” SSD with a 200 GB ext4 partition mounted on the host at /mnt/share/200
- 100 (LXC, unprivileged)
- 101 (LXC, unprivileged)
- 102 (LXC, unprivileged)
- 103 (LXC, privileged): Debian with a bind mount mapping /mnt/share/200 to /storage/interim, set up as Samba share (tested and working)
- 200 (VM): LMDE, connected to Samba share and auto-mounting via fstab edits
PVE 2: 128 GB M.2 SATA partitioned into the default BIOS, EFI, and LVM by Proxmox during installation
- 100 (LXC, unprivileged)
- 101 (LXC, unprivileged)
My current task is to get the 200 GB ext4 partition that is mounted to PVE 1 accessible (read+write) by PVE 1-100, PVE 1-101, PVE 1-102, and the PVE 2 host (if possible). It needs to remain permanently attached / auto-mount on boot to the LXC containers (mostly because I need to know it’s possible before setting up a 12 TB external drive to be shared in the same way) in a way that doesn’t prohibit the use of snapshots within Proxmox.
The Samba share from the privileged Debian container on PVE 1 is working fine, the LMDE VM auto-mounts the share on startup and I can connect to it via my Windows laptop as well. The unprivileged LXCs are unable to mount the share (which appears to be expected, though I was unaware of that restriction when I set the Samba “workaround” up) but they are able to connect to the share via smbclient. I have been looking into using the “lxc.mount.entry” bind mount instead of the “mp#:” bind mount, but have not been able to get it to work. So far I’ve tried these variations appended to /etc/pve/lxc/100.conf:
- lxc.mount.entry = /mnt/share/200 /storage/interim none bind,create=dir 0 0; testing via ls /storage/interim after reboot shows no contents
- lxc.mount.entry = /mnt/share/200 /storage/interim/ none bind,create=dir 0 0; testing via ls /storage/interim after reboot shows no contents
- lxc.mount.entry = /mnt/share/200 /storage/interim none bind,relative 0 0 (when /storage/interim has already been created in the container); testing via ls /storage/interim after reboot shows no contents
- lxc.mount.entry = /mnt/share/200 /var/lib/lxc/100/rootfs/storage/interim none bind,create=dir 0 0; testing via ls /storage/interim after reboot shows "ls: cannot open directory '/storage/interim': Permission denied"
- lxc.mount.entry = /mnt/share/200 /var/lib/lxc/100/rootfs/storage/interim none bind,create=dir,rw,users,uid=0,gid=0,fmask=777,dmask=777 0 0; testing via ls /storage/interim after reboot shows "ls: cannot open directory '/storage/interim': Permission denied"
The last two seemed to be getting... somewhere, so I tried adding the UID and GID mapping in the .conf:
lxc.idmap: u 0 100000 1000 lxc.idmap: g 0 100000 1000
I'm still getting the same permission denied error, though.
I would prefer not to have to replace these containers with privileged versions, but I have pretty much hit my current limit of what I know to test. Is there something obvious I'm overlooking in this setup that would allow this directory to be mounted by an unprivileged container, or an alternate strategy I should try that would meet my needs?
Replication between 2 locations
Hello, I would like to know if vm replication works between two remote and proxmox sites? That is to say on the first site I have a cluster and I would like the vm to be replicated on a remote site in case of a major incident to relaunch everything on the second site. Is it possible?
.pxarexclude woes
I backup all my containers and vm's to a pbs server using pve datacenter backup dashboard. Some containers (2 to be exact) carry large datasets that I want to exclude from the regular backup. Since container backup's are pxar I thought to exclude them with .pxarexclude files but that doesn't seem to work. I find the .pxarexclude files in the backup data accompagnied with the files I tried to exclude from the backup.
So what is the procedure to do this right ?
I would hate to make changes on the proxmox server for this ... the container knows best which files to exclude so the .pxarexclude concept looked perfect.
Proxmox/Debian Updates Failing?
New to Proxmox and trying to get updates working on my first lab installation. I updated the repositories for no-sub and it seems the Proxmox-specific updates are being applied, but I'm I get a lot of 403 Forbidden errors for the Debian updates. Do the deb repos need to be changed as well for a non-prod, test environment?
GitHub - bunkeriot/BunkerM: 🚀 BunkerM: All-in-one Mosquitto MQTT management platform, featuring dynamic security, MQTT ACL management, monitoring,and AI integrations
BunkerM Now Supports Local LLM via LM Studio
Your Mosquitto MQTT broker now has a built-in AI assistant that runs entirely on your own hardware. Connect BunkerM to any model loaded in LM Studio and control your entire IoT setup with plain English, no internet connection required, no data ever leaving your network.
Your MQTT broker now has a built-in AI assistant that runs entirely on your own hardware. Connect BunkerM to any model loaded in LM Studio and control your entire IoT setup with plain English, no internet connection required, no data ever leaving your network.
Why This Matters
Until now, BunkerM's AI features required a BunkerAI Cloud subscription. That works well for most users, but a growing number of deployments cannot send data outside the network, whether due to compliance requirements, limited connectivity, or a preference for keeping infrastructure fully self-contained.
Local LLM mode solves this by routing all AI requests to a model running on your own machine via LM Studio, an open-source desktop app that runs models locally. BunkerM injects live broker context into every request, so the model knows your connected clients, active topics, latest payloads, and statistics, and can act on them directly.
What It Can Do
The local AI has the same execution capabilities as the cloud version for web chat. You can ask it to create clients, publish messages, delete devices, and query live broker state, all in plain English. A few examples:
- "Create 10 sensor clients with random credentials" produces 10 real entries in Mosquitto's dynamic security immediately.
- "What is the current value of home/sensor/temperature?" reads the actual retained payload and returns it.
- "Turn off the conveyor belt" publishes the correct stop payload to the right topic, based on your topic annotations.
The model receives a fresh snapshot of your broker on every message. There is no stale cache. It sees what your broker sees, right now.