Mount Point - Files exist within LXC, but not host

F

fizzik

New Member
Jan 15, 2024
6
1
3
Hey guys. Got a shared mount point created to be shared between 4 LXCs. However, I've got a weird situation.

It appeared to work correctly for a while. However, there are some files being created on one LXC but cannot be seen on another. I thought it was a permissions issue, so I ran a find command to search the entirety of the host, but the file could not be found. Seems to be a great mystery, and I have been thrown for a complete loop as to what could be going on.
 
readyspace said:
Quick checks: was the bind mount active before file creation? And are your LXCs unprivileged so UID/GID mapping could be hiding the file?
Click to expand...
Yes, they are all unprivileged. I did set this as the config for all LXCs:

Code: 
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 101000 1
lxc.idmap: g 1000 101000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535

However, I do suspect you are entirely correct, the mapping is causing the files to be hidden. The tremendous mystery to me, though, is how could they possibly be visible on the LXC but not on the host itself?
 
This might be too technical here but...

That “visible in LXC, missing on host” almost always means the file was written into the container’s rootfs (the bind wasn’t active at that moment or you wrote to a different path), not the shared host dir.

Inside the LXC, run findmnt -T /path/to/shared — if it doesn’t show your host path, you wrote into the CT’s own FS. To recover, stop the CT, pct mount <CTID>, then copy from /var/lib/lxc/<CTID>/rootfs/<that/path> into the real host share.

Since you’re unprivileged with custom idmaps, also ensure the writer runs as the mapped UID (e.g., 1000) so ownership lines up across CTs.

Hope this will work for you.
 
readyspace said:
This might be too technical here but...

That “visible in LXC, missing on host” almost always means the file was written into the container’s rootfs (the bind wasn’t active at that moment or you wrote to a different path), not the shared host dir.

Inside the LXC, run findmnt -T /path/to/shared — if it doesn’t show your host path, you wrote into the CT’s own FS. To recover, stop the CT, pct mount <CTID>, then copy from /var/lib/lxc/<CTID>/rootfs/<that/path> into the real host share.

Since you’re unprivileged with custom idmaps, also ensure the writer runs as the mapped UID (e.g., 1000) so ownership lines up across CTs.

Hope this will work for you.
Click to expand...
Running that command yields:
Code: 
TARGET    SOURCE       FSTYPE OPTIONS
/mnt/data hddpool/data zfs    rw,relatime,xattr,noacl,casesensitive

The container FS itself is very small, so there is no chance it contains the 1TB+ files stored in data. If I remove the mount point and re-launch the container, those files completely disappear.

I will say, I tried making a second mount point, setting its ownership to 1005:1005, and am now copying everything from data to this second mount point. This does appear to be working. The difference is this time I am copying all of the files from the container itself, whereas before, I moved the files from my NAS to /hddpool/data from the proxmox host. Maybe this will fix my issue.
 
  • Like
Reactions: readyspace
Update, appears that copying all the files over via the LXC and decommissioning that old directory seems to have fixed this issue. Still wish I could understand what the actual problem was, but won't say no to it being fixed. Thanks for the help Readyspace!
 
Hi, glad it’s sorted. The root cause was indeed UID/GID mapping mismatch — when files were written by the host, they got ownerships outside the container’s mapped range, making them effectively invisible from inside unprivileged LXCs. Copying from within the container re-applied correct mapped IDs, so visibility lined up again. Good call on rebuilding from inside — that’s the right long-term fix.
 
readyspace said:
Hi, glad it’s sorted. The root cause was indeed UID/GID mapping mismatch — when files were written by the host, they got ownerships outside the container’s mapped range, making them effectively invisible from inside unprivileged LXCs. Copying from within the container re-applied correct mapped IDs, so visibility lined up again. Good call on rebuilding from inside — that’s the right long-term fix.
Click to expand...
Makes sense for the most part, with exception of the files being hidden from the host as well.
 
Yep, that’s actually normal — it’s how unprivileged LXC containers isolate files. The container’s root is mapped to a high UID range on the host (like 101000+), so files written from inside can look “hidden” or owned by unknown users outside. It’s a security feature, not a bug. Your fix worked because copying from inside reapplied the correct mapped IDs.
 
You must log in or register to reply here.
Top Bottom