Restoring LXC - will this erase the mount points or not?

MattD76

New Member
Nov 7, 2025
1
0
1
Hi,

this morning I managed to break my paperless-ngx containers and thus wanted to restore from backup. The container has a mount point from a NAS, that I am passing into it. The config is like this

Code:
arch: amd64
cores: 2
features: keyctl=1,nesting=1
hostname: paperless-ngx
memory: 2048
mp0: /mnt/lxc_shares/nas_rwx/,mp=/mnt/nas
net1: name=net1,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:39:F9:1A,ip=dhcp,tag=20,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-106-disk-0,size=16G
startup: order=100
swap: 512
tags: community-script;document;management
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file


When restoring from the web gui there is a message

1762501104185.png

Which appears inconsistent from the man page, which reads

Note
Since bind and device mount points are never backed up, no files are restored in the last step, but only the
configuration options. The assumption is that such mount points are either backed up with another mechanism
(e.g., NFS space that is bind mounted into many containers), or not intended to be backed up at all.


I naturally don't want the restore operation erase my NAS mount point as this contains all the paperless documents.

What will be erased upon clicking yes?
Thanks in advance for any help!

Best,
Matthias
 
The bind mount (not to be confused with a Mount Point) will probably be removed but that shouldn't delete the source contents.
What I expect to happen is that the CT config will be restored without the bind mount config entry. You should find that in the description afterwards and can add it again. I strongly recommend to test such things with a test guest though.

By the way you can replace
Bash:
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
with
Bash:
dev0: /dev/net/tun
It's what the option in the GUI here does too
1762505462876.png

And to be able to still snapshot the guest (much recommended) also read this.
 
Last edited: