What's happening
Since upgrading from TOS 6 to TOS 7, a Docker container of mine can no longer read files I bind-mount into it from a shared folder on /Volume1. The catch is that the process inside the container runs as an unprivileged user (nobody, uid 65534), not root. Under TOS 6 this worked fine; under TOS 7 every read by that user fails with "Permission denied".
Things that run as root inside the container can read the mounted files without issue — it's specifically the non-root user that's blocked.
What I've verified
The files themselves have permissive modes and I've even added a POSIX ACL granting the uid — getfacl shows the grant and the mask allows it:
Code: Select all
$ getfacl /Volume1/<share>/<file>
user::rw-
user:nobody:r--
group::r--
mask::r--
other::r--Code: Select all
$ sudo -u nobody cat /Volume1/<share>/<file> >/dev/null && echo OK || echo DENIED
DENIEDThe thing that stands out is the mount options on the volume:
Code: Select all
$ findmnt -T /Volume1/<share>
TARGET SOURCE FSTYPE OPTIONS
/Volume1 /dev/mapper/vg0-lv0[/@] btrfs rw,noatime,discard=async,tmacl,space_cache=v2,subvol=/@My questions
- Is my understanding of tmacl correct — that it overrides POSIX permissions/ACLs, so chmod/setfacl no longer grant access to arbitrary uids the way they did on TOS 6?
- What is the supported way to grant a specific uid/gid (e.g. 65534) read access to a shared folder under TOS 7, so a non-root container process can read bind-mounted files? Is there a Control Panel / File Manager permission setting for this, or must it be done at the CLI?
- Does /usr/sbin/aclconv apply here, and if so what's the correct usage to add a tmacl grant for a given uid/gid on a folder (recursively)? I've seen the general "btrfs property set … ro false" → setfattr → aclconv → "ro true" sequence mentioned, but not the exact aclconv syntax or whether it can target a raw numeric uid.
- Is the recommended pattern instead to run the container as a real TOS user/group (one that has been granted access to the shared folder in the UI) and map the container to that uid/gid — rather than trying to grant the generic nobody uid?
- Is there any mount-level option (e.g. mounting that subvolume with standard "acl" instead of "tmacl") that's supported/safe, or would that break TOS's permission management?
I just want a non-root process (running as an arbitrary uid) to be able to read a handful of config/data files from a shared folder, in a way that's supported and survives reboots/upgrades — without running the container as root and without fighting the permission system.
Any guidance on the intended TOS 7 workflow for this would be much appreciated. Thanks!

