Mount Point - Files exist within LXC, but not host

[fizzik]

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]

Quick checks: was the bind mount active before file creation? And are your LXCs unprivileged so UID/GID mapping could be hiding the file?

 

[fizzik]

Quick checks: was the bind mount active before file creation? And are your LXCs unprivileged so UID/GID mapping could be hiding the file?

Yes, they are all unprivileged. I did set this as the config for all LXCs:

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?

 

[readyspace]

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.

 

[fizzik]

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.

Running that command yields:

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.