Yeah something definitely seems up with TrueNAS’s NFS server.
I set up a fresh NFS server on that same Debian 13 VM, configured it similarly to TrueNAS (sec=sys,rw,all_squash,anonuid=1001,anongid=1001,no_subtree_check and NFSv4) and it not only rejects a chown root:root command, but both mv and cp -a work without error. Looking at the strace for those commands with the Debian 13 NFS server, it seems like mv and cp -a both recognize and silently accept that fchown returns EPERM and stop attempting to set ownership but still exit successfully.
I notice the folks here are talking about 24.04 and 24.10, so I guess the next step is to try out 25.04 and see if its behavior is any better.
Nope, 25.04 allows a chown root:root within an NFS share configured with mapall user/group too. Sadness. 
I’m much more uncertain about using a TrueNAS NFS share for Docker volume storage now since processes in containers are often root. I discovered this when moving a volume’s existing contents into a newly created NFS share. It does seem like creating files as root on the client correctly applies the anonuid/anongid, but the fact that TrueNAS’s behavior is confusing even basic tools like mv and cp does not inspire confidence that things are going to be problem-free once I start layering Docker and other arbitrary software on top.
Edit: I also don’t seem to be able to create a bug in the TrueNAS Jira…not sure if that’s Jira being Jira or an intentional configuration by ixSystems.
This should be fixed in master / 25.10.2. Test that before creating any tickets.
Checking TrueNAS Software Status | TrueNAS Documentation Hub it looks like 25.10.2 isn’t even recommended for early adopters yet, so that’s a bit too cutting edge for me to put even on my home setup. Good to hear a fix should be coming though!
Oh I see why you mentioned master now; 25.10.2 isn’t even tagged and released yet. Not familiar with y’all’s internal source control practices. 
@awalkerix Perhaps this is unlikely, but any chance of getting the mentioned fix backported to 25.04? Not sure if that’s a matter of a cherry-pick or something more effortful, or whether that’s something that can be pushed out in a maintenance release like a 25.04.2.7 or if it would require a 25.04.3 release that isn’t planned.
I’d be happy to spin up a 25.10.1-MASTER VM, now that I’ve found the nightly images, and test that the fix works as expected if that helps motivate a backport at all. 
Edit: Actually, perhaps I haven’t found the images you’re referring to… download.truenas.com | Storj only seems to have 25.10.1 images through the end of October 2025.
Aha! This actually seems to be a bug specific to datasets with their ACL type set to “SMB/NFSv4”. I did confirm that in master (i.e. the 26.04 nightlies) that this seems to be fixed, even if using an NFSv4 ACL on a dataset. No idea about 25.10.2 since I was not able to find any pre-release images for that.
However, I also discovered that as long as the ZFS dataset is configured to use POSIX ACLs, then 25.04.2 correctly prohibits chown to a different uid/gid than the configured mapall uid/gid! I haven’t tested whether this is also true on 24.10 or 24.04, since I’ve now updated my primary install to 25.04.2. For others here that are experiencing this, I would recommend first changing the shared dataset’s ACL type to POSIX and testing if that works on your current version, and if not then consider updating to 25.04.2 where it will.
Also, note that it’s the dataset’s ACL type that matters, not whether or not you actually have an ACL configured! If the dataset’s ACL type is “SMB/NFSv4”, then even if you only use simple UNIX permissions under 25.04.2 NFS shares configured with mapall user/group allow chown to a different uid/gid. Gotta change the dataset’s ACL type to POSIX, even if you aren’t setting an ACL.
One other note for searchability; “mapall user/group” is the TrueNAS option name for this. In NFS option parlance this is “all_squash,anonuid=X,anongid=Y”.
