Are you testing as the container root? If so, then you’d need to add the unprivileged root account to the ACL. Otherwise yo’d need to su to myuser in the container. If it still does not work, file a bug ticket.
If I understand correctly your talking about the root user from within the container.
I added that account “truenas_container_unpriv_root” for testing onto this dataset. While I don’t fully understand what this user does, from within the Container, I can now access that folder as root, as the expected normal behavior as root rather than getting an “Operation not permitted” error.
However, the mapping does not function, even with “truenas_container_unpriv_root” added it is mapped as nobody (65534) nogroup (65534), where I would expect the correct uid and gid.
I did see other posts where people have added that user, but it might be masking the mapping not working.
So a bug report… What info would be wanted for that, just the debug file or would outputs suffice?
What ACL type are you using for storage imported in the container? NFSv4 ACL type will most likely be unsupported by container tools. The ACLs are interpreted properly inside container context but you will not have tools to read it properly. E.g. truenas_getfacl for path will show ACL in host, but running getfacl (which only reads a POSIX1E ACL) will not work properly.
Overall, I think most likely trying to concurrently modify ACL from both host and container will not be a source of happiness. It’s better to just lock ACL down on the host such that the container users can read / write data, but not modify permissions.
Its not my normal experience tbh, but you’ll know more than me. I did simplify, it to just posix, stripping the ACL and it still had the same behavior. But confirmation from others that UID and GID per the mapping are representative in the container, would be helpful?
Forgive me here; I could be on the wrong track entirely.
While I don’t fully understand what this user does […], the mapping does not function, even with “truenas_container_unpriv_root” added it is mapped as nobody (65534) nogroup (65534), where I would expect the correct uid and gid.
Do I understand you correctly that the “correct” uid and gid would be 0, and that you’re expecting the unprivileged root user to operate as uid 0?
That built-in user is uid 2147000001. If you left “Map to the same UID in the container” checked, then I’d expect the internal user to have that same uid, maybe presenting to older APIs as 65534. If you tried to map (translate, vs pair) the contained user to 0 then I’d expect TrueNAS to complain: you may not assign uid 0 to a non-privileged user.
If this had been working as expected in 25.10 and it changed in 26: might you have been running the container in privileged mode then, and are only seeing the unprivileged root behavior now?
Again: humble apologies if I’m off-base. I don’t mean to second-guess, but to compare notes.
TBH, I havn’t looking into the mapping of “truenas_container_unpriv_root”. From my small amount of testing I did, it feels like “normal” root beaviour, where the root user has access dispite the uid. Without this, I get “operation not permitted” as root. In fact I now want to go back and test… this unpriv_root.
As the mapping is for the data permissions, then your right in saying I should have a user within the container with the correct id. I’d expect, if working, root would have access, despite ids and a different user with different uid would not, unless a create a group within the container that has the correct configuration.
So what I’d expect:
ls -ln outside the container and folder to mount would show me 1000:2000.
Mapping uid 1000 and gid 2000 is configured.
ls -ln inside the container and mount point would show me 1000:2000.
What I currently get:
ls -ln outside the container and folder to mount would show me 1000:2000.
Mapping uid 1000 and gid 2000 is configured.
ls -ln inside the container and mount point is showing me 65534:65534.
Therefore no privledge mode/configuration is needed.
Since BETA.1 there has been alot of change on the containers, I have the feeling the devs will leave this one until BETA.2 and it’s scheduled release is 28th, so it will be fixed in relation to other issues.
It sounds like the same issue. I was hoping BETA.2 would be out by now, it was due 2 weeks ago, but the bug report I created now has a resolution for RC.1 that is scheduled for the 30th June, so I have no idea what is happening with this release.
Ah I see. Those are code freeze dates, not actual release dates. So after that date it goes into a QA testing cycle and devs are only submitting bug fixes for issues discovered in testing. Time to release after code freeze can vary.
FYI for those affected. We confirmed there’s an issue. Fix is in review and targeted for BETA.2.
Thanks to everyone who filed bug tickets! The detailed feedback in our bugtracker makes these beta cycles better so that we have a stronger 26 release.
it will be fixed in relation to other issues.