Permission and ownership issues with NFSv4 and rsync [Unraid 6.10.2]

[T0a]

Hi 👋,

 

I recently upgraded to Unraid 6.10.2 and try to backup another Linux host via NFS4 and rsync to my Unraid server. The same procedure worked with NFS3 and rsync in the past. However, after upgrading and switching to NFS4 the files do not preserve their ownership anymore and I receive errors from rsync in my client logs as follows.

 

Exemplary, an error from rsync. 

11/06/2022 10:30:28 rsync: chown "/mnt/backup/opt/gitea" failed: Operation not permitted (1)

 

User permission comparison:

root@client:/mnt/backup/opt/gitea# ls -ahl /mnt/backup/opt/gitea/
total 8.0K
drwx------ 1 nobody nogroup   58 Jan  2 13:30 .
drwx------ 1 nobody nogroup 4.0K Jun  4 15:06 ..
drwx------ 1 nobody nogroup  158 Jun 11 00:00 backup
-rw------- 1 nobody nogroup  491 Jun 11 10:31 docker-compose.yml
root@client:/mnt/backup/opt/gitea# ls -al /opt/gitea/
total 20
drwxr-xr-x  4 toa  toa  4096 Jan  2 13:30 .
drwxr-xr-x 30 root root 4096 Jun  4 15:06 ..
drwxr-xr-x  2 1000 1000 4096 Jun 11 00:00 backup
-rw-r--r--  1 toa  toa   491 Nov 26  2021 docker-compose.yml
drwxr-xr-x  5 root root 4096 Dec 28  2020 gitea

User id and group for user

root@client:/# id toa
uid=1000(toa) gid=100(users) groups=100(users),20(dialout),995(docker)
root@unraid:/# id toa
uid=1000(toa) gid=100(users) groups=100(users)

 

The rsync commands that I execute as root user on the Linux hosts to mount the NFS share from the Unraid server:

mount -t nfs4 192.168.178.21:/mnt/user/backup/clients/client /mnt/backup
...
rsync -av --delete --delete-excluded $OPT_EXCLUDES /opt /mnt/backup

 

Before, as an example the file 'docker-compose.yml' showed the owner and group 'toa' in the remote share on the client.

 

My research lead me to this article. On the client side, I then set "NEED_IDMAPD=yes" and "NEED_GSSD=no" in the file '/etc/default/nfs-common'. I didn't enable the 'Domain' setting in the '/etc/idmapd.conf' file as I couldn't find that setting in Unraid. Afterwards, I restarted the client and tried again with the same errors.

 

Would love to get some help on this problem. Feel free to request further information for troubleshooting. Thank you in advance!

 

 

Edited December 10, 2022 by T0a

[dlandon]

4 hours ago, T0a said:

rsync commands that I execute as root user:

I assume these are commands on Unraid.  If so use the UD Plugin to mount the remote NFS share as you are not mounting the NFSv4 with any options.  It will make management of the remote share a lot easier.  UD will also manage a default set of rules that should work in most cases.

 

Also, post your diagnostics zip file for further help.

[T0a]

36 minutes ago, dlandon said:

I assume these are commands on Unraid.  If so use the UD Plugin to mount the remote NFS share as you are not mounting the NFSv4 with any options.  It will make management of the remote share a lot easier.  UD will also manage a default set of rules that should work in most cases.

 

Also, post your diagnostics zip file for further help.

 

No, I execute these commands on the Linux client. It mounts a backup share from the Unraid server and then rsyncs the data to the share.

 

Update:

 

Seems like the ownership issue only occurs when using the root user:

 

toa@client:~$ sudo umount /mnt/backup
toa@client:~$ sudo mount -t nfs4 192.168.178.21:/mnt/user/backup/clients/ /mnt/backup
toa@client:~$ touch /mnt/backup/
toa@client:~$ touch /mnt/backup/file
toa@client:~$ sudo umount /mnt/backup
toa@client:~$ sudo su
root@client:# sudo mount -t nfs4 192.168.178.21:/mnt/user/backup/clients/ /mnt/backup
root@client:# touch /mnt/backup/file2
root@client:# ls -ahl /mnt/backup/
total 3.8G
drwxrwxrwx 1 root   root     115 Jun 11 15:34 .
drwxr-xr-x 3 root   root    4.0K Nov 17  2019 ..
-rw-r--r-- 1 toa    users      0 Jun 11 15:29 file
-rw-r--r-- 1 nobody nogroup    0 Jun 11 15:34 file2

 

Edited June 11, 2022 by T0a

[dlandon]

23 minutes ago, T0a said:

 

No, I execute these commands on the Linux client. It mounts a backup share from the Unraid server and then rsyncs the data to the share.

 

Check your NFS rules on the client.  They affect permissions.  This is what UD uses when mounting remote NFS shares:

*(sec=sys,rw,insecure,anongid=100,anonuid=99,no_root_squash)

 

[T0a]

On 6/11/2022 at 3:38 PM, dlandon said:

 

Check your NFS rules on the client.  They affect permissions.  This is what UD uses when mounting remote NFS shares:

*(sec=sys,rw,insecure,anongid=100,anonuid=99,no_root_squash)

 

 

Indeed that solved the problem. Thank you so much! For reference, I clicked on the tab shares and selected the backup share. Then, under "Nfs Security Settings", I modified the existing rule to "<ip>(sec=sys,rw,insecure,anongid=100,anonuid=25699,no_root_squash)", where <ip> is the address of the Linux client.

 

Update: Is there a way to set the options globally for NFS instead of per rule and IP for all shares? The rule field seems to have a length restriction. Thus, I cannot technically add the same options to all IPs.

Edited December 10, 2022 by T0a

[dlandon]

2 hours ago, T0a said:

Update: Is there a way to set the options globally for NFS instead of per rule and IP for all shares? The rule field seems to have a length restriction. Thus, I cannot technically add the same options to all IPs.

Are you talking about on Unraid shares?  I don't think there is a global setting that applies to all on Unraid.

 

Can you not set the rule to apply to all ip addresses by setting the "*" instead of individual ip addresses?

[T0a]

On 6/11/2022 at 6:25 PM, dlandon said:

Are you talking about on Unraid shares?  I don't think there is a global setting that applies to all on Unraid.

 

Can you not set the rule to apply to all ip addresses by setting the "*" instead of individual ip addresses?

 

This will allow everyone in my network to access the NSF shares, right? I would rather try to avoid that. As of now, only certain IP addresses have access to the shares. However, I cannot apply the options to these IP addresses as the rule input field has a size limit.

Edited December 10, 2022 by T0a

[T0a]

On 6/11/2022 at 11:54 PM, T0a said:

I cannot apply the options to these IP addresses as the rule input field has a size limit

 

I have observed some work regarding this problem in Github. Unfortunately, both changes got reverted.

• Allow multiple rows in NFS rule (4e25bc8cb158b31e7c5ed36f133713bef2d4e35c, revert)
• NFS security rule: change input to textarea, which allows more input (d6b67b44aa6909ed72b75d4238055eddc89ddf99, revert)

I really hope Limetech will tackle the problem in one of their next releases.