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?