LXC migration fails with "cannot migrate local bind mount point" although bind mount is shared NFS on both cluster nodes (PVE 9.2.6)

S

Steefie

New Member
Aug 2, 2026
4
0
1
Hello,


I have encountered what appears to be an issue with LXC migration on Proxmox VE 9.2.6.


After several hours of troubleshooting, I reduced the problem to a minimal reproducible example.


Environment​


  • Proxmox VE 9.2.6
  • pve-container 6.1.12
  • Two-node cluster
  • QDevice configured and working correctly
  • Synology NAS using NFS
  • Both nodes run identical package versions

Shared NFS mount​


The following NFS export is mounted on both nodes:
192.168.178.25:/volume1/Media

Shared NFS mount​


The following NFS export is mounted on both nodes:
192.168.178.25:/volume1/Media

Mount point:
/mnt/nas_media

Verification:
findmnt /mnt/nas_media
Both nodes report the same NFS source.


Minimal reproducible example​


I created a brand new Debian 12 LXC container (CT999).


Configuration:
arch: amd64
cores: 1
hostname: test-migrate
memory: 1024

mp0: /mnt/nas_media,mp=/mnt/test

net0: name=eth0,bridge=vmbr0,ip=dhcp,type=veth

rootfs: NAS_Media:999/vm-999-disk-0.raw,size=4G

unprivileged: 1
The bind mount works correctly.


Example:
pct exec 999 -- ls /mnt/test
returns the contents of the NAS.

Migration​


After stopping the container:
pct migrate 999 pve2

Result:
ERROR: migration aborted (duration 00:00:00):
cannot migrate local bind mount point 'mp0'
migration aborted

The migration aborts immediately.


Additional observation​


According to the Proxmox documentation, adding shared=1 to the bind mount should allow migration of shared bind mounts.


However, if I use:
mp0: /mnt/nas_media,mp=/mnt/test,shared=1

the configuration is rejected with:
shared: property is not defined in schema

What has been verified​


  • Two-node cluster is healthy.
  • QDevice works correctly.
  • Quorum is healthy.
  • Both nodes run identical versions.
  • Same kernel on both nodes.
  • Same NFS export.
  • Same mount point on both nodes.
  • Bind mount works correctly inside the container.
  • Problem is reproducible with a completely fresh Debian 12 container.

Questions​


  1. Is this expected behaviour in Proxmox VE 9.2.6?
  2. Has anything changed regarding bind mount migration?
  3. Why is shared=1 rejected although it is documented?
  4. Could this be a regression?

Thank you for your time.


Kind regards,


Steefie
 
please post

- pveversion -v
- pct config XXX
 
Thank you for your reply.

Here are the requested outputs from the source node (pve).

### pveversion -v

```text
proxmox-ve: 9.2.0 (running kernel: 7.0.14-8-pve)
pve-manager: 9.2.6 (running version: 9.2.6/7f8d010005bd72cb)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0.14-8-pve-signed: 7.0.14-8
proxmox-kernel-7.0: 7.0.14-8
proxmox-kernel-7.0.12-1-pve-signed: 7.0.12-1
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
proxmox-kernel-7.0.2-4-pve-signed: 7.0.2-4
proxmox-kernel-7.0.0-3-pve-signed: 7.0.0-3
proxmox-kernel-6.17: 6.17.13-21
proxmox-kernel-6.17.13-21-pve-signed: 6.17.13-21
proxmox-kernel-6.17.13-14-pve-signed: 6.17.13-14
proxmox-kernel-6.17.13-13-pve-signed: 6.17.13-13
proxmox-kernel-6.17.13-11-pve-signed: 6.17.13-11
proxmox-kernel-6.17.13-9-pve-signed: 6.17.13-9
proxmox-kernel-6.17.13-6-pve-signed: 6.17.13-6
proxmox-kernel-6.17.13-2-pve-signed: 6.17.13-2
proxmox-kernel-6.17.4-2-pve-signed: 6.17.4-2
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.3-pve2
corosync: 3.1.10-pve3
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.2
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.20
libpve-guest-common-perl: 6.0.5
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.7
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.7
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.3-1
proxmox-backup-file-restore: 4.2.3-1
proxmox-backup-restore-image: 1.0.0
proxmox-enterprise-support-keyring: 1.1
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.6
pve-cluster: 9.1.6
pve-container: 6.1.12
pve-docs: 9.2.3
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.5
pve-firmware: 3.18-5
pve-ha-manager: 5.2.5
pve-i18n: 3.9.0
pve-qemu-kvm: 11.0.3-1
pve-xtermjs: 6.0.0-2
qemu-server: 9.2.1
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.3-pve1
```

### pct config 999

```text
arch: amd64
cores: 1
features: nesting=1
hostname: test-migrate
memory: 1024
mp0: /mnt/nas_media,mp=/mnt/test
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:4B:06:6C,ip=dhcp,type=veth
ostype: debian
rootfs: NAS_Media:999/vm-999-disk-0.raw,size=4G
swap: 512
unprivileged: 1
```
 
okay, then please do

"pct set 999 --mp0 /mnt/nas_media,mp=/mnt/test,shared=1"

and retry
 
Thank you!

That solved the issue.

I ran:

```bash
pct set 999 --mp0 /mnt/nas_media,mp=/mnt/test,shared=1
```

After that, `pct config 999` shows:

```text
mp0: /mnt/nas_media,mp=/mnt/test,shared=1
```

I then retried the migration:

```bash
pct migrate 999 pve2
```

The migration now completes successfully:

```text
2026-08-06 16:47:40 starting migration of CT 999 to node 'pve2' (192.168.178.101)
2026-08-06 16:47:40 volume 'NAS_Media:999/vm-999-disk-0.raw' is on shared storage 'NAS_Media'
2026-08-06 16:47:40 ignoring shared 'bind' mount point 'mp0' ('/mnt/nas_media')
2026-08-06 16:47:40 start final cleanup
2026-08-06 16:47:40 migration finished successfully (duration 00:00:01)
```

Thank you very much for your help!

One question: I had previously added `shared=1` manually to the LXC configuration file, but the migration still failed. Is there a difference between editing the configuration file manually and using `pct set` that explains this behavior?
 
it sounds like you might have typoed/messed up the formatting somehow.. other than locking/protection against concurrent modification, editing manually or via the API doesn't make a difference..
 
Thanks Fabian, that did the trick!

Really appreciate you taking the time to help me figure this out. It turned out to be a lot simpler than I was making it.

Thanks again!
 
You must log in or register to reply here.
Top Bottom
Back