Well I'm a bit embarrassed and I thank you for the help. The problem was that I had a recursive rpool snapshot on a non-root dataset mounted at '/'... As soon as I unmounted it, changed canmount to noauto, and changed the mountpoint to the path where the remote snapshot lives, for good measure, I tested 3 unprivileged LXCs and they all started fine.
I also reproduced the error by changing the mountpoint back to '/' and mounting it again, same errors seen again on LXC startup.
Code:
root@host:~# zfs list -ro canmount,mountpoint,mounted,name
CANMOUNT MOUNTPOINT MOUNTED NAME
...
noauto / no bigpool/pvebupz/20221113v2
...
...
on / yes exos/rpoolbupz_all_20221121
...
...
on /homepool/iso yes homepool/iso
on /homepool/lxc yes homepool/lxc
on /homepool/vm yes homepool/vm
on /rpool yes rpool
on /rpool/ROOT yes rpool/ROOT
on / yes rpool/ROOT/pve-1
...
...
When I read your last question a lightbulb went on.
Thanks for your time, I hope my stumbling onto this at least helps someone else in the future. I had noticed in creating and sending/receiving rpool snapshots in the past that they default to canmount==on with a mountpoint==/ and had manually fixed this prior to reboot, but not in this case unfortunately.
What I mean is creating a recursive snapshot like this:
Code:
root@host:~# zfs snapshot -r rpool/ROOT/pve-1@20221202 && zfs send -Rwv rpool/ROOT/pve-1@20221202 | pv | zfs receive -Fuv exos/rpoolbupz_all_20221202
Results in a snapshot with the following attributes:
Code:
root@host:~# zfs list -ro canmount,mountpoint,mounted,name | head
CANMOUNT MOUNTPOINT MOUNTED NAME
on / no exos/rpoolbupz_all_20221202
And without changing canmount to noauto or the mountpoint to something other than '/', it will mount there on reboot.
I spent an hour or two in the irc support channels for lxc (#lxc @ libera.chat) regarding this and they suggested I create a thread on their forum as well. So I will update that too. Sorry for the hassle.
