NFS mapall user and group broken for mv

TrueNAS General
,
1

I have an odd issue since migrating from a RHEL NFS server to TrueNas.

I have a media mount where I use mapall to make sure all files are written as the correct user on the remote NAS Server. This is restricted to a couple of IP addresses - for example

/Share/Video         192.168.3.32/255.255.255.255(ro,root_squash,sync,all_squash,anonuid=2001,anongid=2001)

With this old setup I could mv or cp a file onto the NFS mount and ultimately it would have the uid/gid of 2001.

Under TrueNas I’ve tried to setup the same configuration via the webui which results in the following entry in /etc/exports.

"/mnt/mediapool/Video"\
192.168.3.32(sec=sys,rw,anonuid=2001,anongid=2001,all_squash,insecure,no_subtree_check)

with a TrueNAS NFS mount

  • “cp” everything appears to work correctly, but results in the wrong umask of 600.
  • “mv” the file retains the uid/gid of the original user on the source machine running Fedora.

With my old RHEL NFS server both CP and MV preserved the anonuid/anongid values and the correct umask.

Any ideas as I’d prefer to not use a CIFs mount for this mult-user share.

2

Are you copying from fedora to TrueNAS?

3

mv generally just relinks a file. It does not alter file permissions in any way (and shouldn’t).

4

Yes I’m moving or copying a file from Fedora based laptops to the TrueNas servers.

I need a way for multiple users to copy files to the server, and ultimately have the same user own the files on the remote share. This worked fine in the past, but I’m having weird permission issues with TrueNAS

5

So for cp… what umask are you wanting?
Is there a way of setting this after the copy?

6

Ah, I had assumed you your referring to an actual server-side mv which would invoke a rename.

7

Ok it looks like my default umask on Fedora has changed from 022 to 077 which explains the CP issues.

With a copy from Fedora → TrueNas I can chmod the file later, but I’ve now fixed the default umask back to something sensible for home use.

Moving files from Fedora → Truenas is weird as despite using mapall the uid is being preserved, and once the file is on the server I can’t chown/chmod the file as I no longer have permissions.

8

Can you be specific if you think there is still a problem…

9

Yes I believe there is an issue. With mapall I’d expect that when writing a file to NFS via mv or cp the uid would match the mapall uid.

This is only happening with a “cp”

10

It’s a bit surprising… under the cover, both are copy commands that get turned into writes.

I wonder if your client is issuing a different write command option to try to preserve the original owner.??

What client OS? Can you verify with another OS?

In the meantime… it looks like cp is the better option.

11

Clients are Fedora 40, and the issue still occurs with TrueNas Scale 24.04.2

12

It would be useful to know if there are issues with other client OSes…

13

Behaves as expected here:


root@kubuntu:~# ssh admin@192.168.0.56 "cat /etc/exports"
admin@192.168.0.56's password: 


"/mnt/Spool/isos"\
        192.168.0.0/24(sec=sys,rw,no_root_squash,no_subtree_check)
"/mnt/Spool/cp-mv-test"\
        192.168.0.0/24(sec=sys,rw,anonuid=1000,anongid=100,all_squash,no_subtree_check)
root@kubuntu:~# nfsstat -m
/home/chris/NFS from 192.168.0.56:/mnt/Spool/cp-mv-test
 Flags: rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.201,local_lock=none,addr=192.168.0.56

root@kubuntu:~# ls -ld /home/chris/NFS
drwxrwxr-x 2 root users 4 Jul 19 11:56 /home/chris/NFS
root@kubuntu:~# echo "made by root" > root2.txt 
root@kubuntu:~# mv root2.txt  /home/chris/NFS/
mv: failed to preserve ownership for '/home/chris/NFS/root2.txt': Operation not permitted
root@kubuntu:~# ls -l /home/chris/NFS/
total 1
-rw-r--r-- 1 chris users 13 Jul 19 12:02 root2.txt
root@kubuntu:~#
14

Ok testing with an ubuntu 22.04 client

export with all_squash

"/mnt/datapool-z2/Media/Test"\
	192.168.0.25(sec=sys,rw,anonuid=1001,anongid=1001,all_squash,insecure,no_subtree_check)

Mount on the client - one of my mythtv frontends

root@mythfe1:/tmp# nfsstat -m
/mnt/Test from truenas:/mnt/datapool-z2/Media/Test
 Flags:	rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.25,local_lock=none,addr=192.168.0.3


root@mythfe1:/tmp# ls -ld /mnt/Test/
drwxrwsr-x 186 kodi users 237 Jul 23 14:01 /mnt/Test/

root@mythfe1:/tmp# id 1001
uid=1001(kodi) gid=1001(kodi) groups=1001(kodi),24(cdrom),29(audio),44(video),46(plugdev),102(netdev)

testing cp and mv as my mythfe user (id=1000)

mythfe@mythfe1:~$ cd /tmp
 
mythfe@mythfe1:/tmp$ echo dwdw  > move
mythfe@mythfe1:/tmp$ mv out /mnt/Test/test/
mv: preserving permissions for ‘/mnt/Test/test/move’: Operation not permitted
mythfe@mythfe1:/tmp$ echo dwwddw > copy
mythfe@mythfe1:/tmp$ cp new  /mnt/Test/test/

mythfe@mythfe1:/tmp$ ls -l /mnt/Test/test/
total 17
-rw-rw-r-- 1 kodi   users  7 Jul 23 14:03 copy
-rw------- 1 mythfe mythfe 5 Jul 23 14:02 move

Testing as the root user

root@mythfe1:/tmp# echo wdwdw > root.mv
root@mythfe1:/tmp# mv root.mv /mnt/Test/test/
mv: preserving permissions for ‘/mnt/Test/test/root.mv’: Operation not permitted

root@mythfe1:/tmp# echo wdwdw > root.cp
root@mythfe1:/tmp# cp root.cp /mnt/Test/test/
root@mythfe1:/tmp# ls -l /mnt/Test/test/
total 34
-rw-rw-r-- 1 kodi   users  7 Jul 23 14:03 copy
-rw------- 1 mythfe mythfe 5 Jul 23 14:02 move
-rw-r--r-- 1 kodi   users  6 Jul 23 14:08 root.cp
-rw------- 1 root   root   6 Jul 23 14:07 root.mv

so the existing local UID/GID is being preserved when I perform a mv.

15

I am wondering if anyone was able to find the issue here as I am seeing it exactly as described since I upgraded from Core to Scale a few months ago.

I can verify it is happening across Linux distros (RHEL, Ubuntu, Arch). Anything that copies the file (cp, rsync) or writes it directly (touch, wget, various python scripts) sets the expected MAPALL permissions that are set on the share. However only mv seems to be keeping the existing ownership.

# mv -v test.txt /mnt/vault/ISO/
copied 'test.txt' -> '/mnt/vault/ISO/test.txt'
mv: preserving permissions for ‘/mnt/vault/ISO/test.txt’: Operation not permitted
removed 'test.txt'

So, while it seems to be erroring that its not permitted to preserve the permissions, it still somehow is.

16

Still haven’t found a fix on my side. I’m still running 24.04 at present as I need to sort out Docker container networking before migrating to 24.10.

17

Fresh test from my daily laptop

Server


"/mnt/datapool-z2/Media/Test"\
	192.168.4.27(sec=sys,rw,anonuid=1001,anongid=1001,all_squash,insecure,no_subtree_check)

Client


fsstat -m
/mnt/Test from truenas:/mnt/datapool-z2/Media/Test
 Flags:	rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.57,local_lock=none,addr=192.168.0.3



echo wddw > testfile
mv testfile /mnt/Test/
ls -l /mnt/Test/testfile 

-rw-------. 1 root root 5 Nov 11 13:31 /mnt/Test/testfile

echo ddwdwd > cp.test
cp cp.test  /mnt/Test/
ls -l /mnt/Test/cp.test 

-rw-------. 1 1001 users 7 Nov 11 13:37 /mnt/Test/cp.test

Any ideas?

18

I’m seeing the same issue with TrueNAS Goldeye and Debian13 (also I noticed it first on Synology as NFS client):

root@debian13:~# touch /mnt/truenas-goldeye/test.txt
root@debian13:~# ls -la !$
ls -la /mnt/truenas-goldeye/test.txt
-rwxrwxr-x+ 1 568 4000 0 Nov 26 19:31 /mnt/truenas-goldeye/test.txt

root@debian13:~# touch test2.txt
root@debian13:~# touch test3.txt
root@debian13:~# ls -la
drwx------  4 root root 4096 Nov 26 19:32 .
drwxr-xr-x 18 root root 4096 Nov 11 22:41 ..
-rw-------  1 root root 3712 Nov 23 01:12 .bash_history
-rw-r--r--  1 root root  607 May 12  2025 .bashrc
drwxr-xr-x  3 root root 4096 Nov 11 23:24 .cache
-rw-r--r--  1 root root   35 Nov 11 22:40 .forward
-rw-------  1 root root   20 Nov 23 00:19 .lesshst
-rw-r--r--  1 root root  132 May 12  2025 .profile
-rw-------  1 root root 1024 Nov 11 22:42 .rnd
drwx------  2 root root 4096 Nov 11 22:42 .ssh
-rw-r--r--  1 root root    0 Nov 26 19:32 test2.txt
-rw-r--r--  1 root root    0 Nov 26 19:32 test3.txt

root@debian13:~# cp test2.txt /mnt/truenas-goldeye/

root@debian13:~# mv test3.txt /mnt/truenas-goldeye/
mv: preserving permissions for ‘/mnt/truenas-goldeye/test3.txt’: Operation not permitted

root@debian13:~# ls -la /mnt/truenas-goldeye/
drwxrwxr-x+ 4  568  4000    7 Nov 26 19:32  .
drwxr-xr-x  4 root root  4096 Nov 25 20:12  ..
-rwxrwxr-x+ 1  568  4000    0 Nov 26 19:32  test2.txt
-rwxrwxr-x+ 1 root root     0 Nov 26 19:32  test3.txt
-rwxrwxr-x+ 1  568  4000    0 Nov 26 19:31  test.txt

My exports also says: (sec=sys,rw,anonuid=568,anongid=4000,all_squash,no_subtree_check)

PS. Synology NFS client has this issue even when doing copy (in the UI, not sure what it is under the hood, but I assume it’s not `mv`).

1 Like
19

I’m not seeing this with a generic RHEL or Ubuntu NFS server so I’m not sure what is different on True NAS.

20

Yikes, this seems like quite the bug to have sat around for over a year, especially if it is unique to TrueNAS NFS servers like the OP notes. @Steven_Ellis have you reported an actual bug on Jira yet?

I discovered this today with a TrueNAS 24.10 server (24.10.2.2 specifically) and can reproduce it with many different Linux clients, including Flatcar Linux, Proxmox 8.4.0, and a completely fresh Debian 13 VM. It seems to occur using either mv and cp -a, which preserves attributes including uid/gid, on the client. I also confirmed that cp –-preserve=ownership is sufficient.

Unfortunately I haven’t located any useful logging on the server side that might give hints as to what is going on, but I observe the same behavior that others have reported where preserving permissions fails on the client-side with Operation not permitted, and the resulting file has root/root uid/gid despite having “mapall user/group” configured for the share.

Here is an strace of 3 different commands, cp –-preserve=ownership followed by plain cp followed by mv, run from said fresh Debian 13 VM as client to the TrueNAS NFS server. The 1st and 3rd commands fail and result in a file owned by root:root despite NFS being configured with “allsquash”.

I actually think the “Operation not permitted” is a bit of a red herring. It looks to me like the fchown to root on the 1st and 3rd commands (at line 181 and 554 respectively) is succeeding when I’m guessing it shouldn’t? Or perhaps it’s something about the fchown/fchmod together; those are the primary two syscalls that are present on the 1st and 3rd commands but aren’t on the 2nd.