Help me understand strange chown behavior

General Discussion
1

I am trying to sync a directory from my Dietpi install to a mounted NFS network drive on TrueNAS. When running dietpi-sync, I receive the error rsync: [receiver] chown “/mnt/nfs_client/dietpi-sync/truenas_dietpi/(INSERT FILE NAME HERE)” failed: Invalid argument (22). At the end of the sync, I receive the error mv: failed to preserve ownership for ‘/mnt/nfs_client/dietpi-sync/.dietpi-sync.log’: Invalid argument.

Things I’ve tried:

Created user with same name and uid on both machines and chmod the Dietpi directory I want to sync so that the user I created has full access

Stripped all ACLs from destination TrueNAS dataset

Neither of these changes worked. I am new to Linux permissions. Can you please tell me why this error is occurring and how I can fix it?

2

Best to share some examples for permission and file system

ls -la /mnt/nfs_client/dietpi-sync/
3

Here you go:

dietpi@DietPi:~$ sudo ls -la /mnt/nfs_client/dietpi-sync/
total 250
drwxrwxrwx 16 nobody nogroup    18 Jan  1 01:32 .
drwxrwxrwx  3 nobody nogroup     3 Dec 30 00:46 ..
-rw-r--r--  1 nobody nogroup 92865 Jan  1 01:32 .dietpi-sync.log
drwxrwxrwx  4 nobody nogroup     9 Oct 29  2023 buildkit
drwxrwxrwx  4 nobody nogroup     4 Jan 20  2024 containers
drwxrwxrwx  5 nobody nogroup    11 Dec 31 04:54 dietpi
-rwxrwxrwx  1 nobody nogroup    36 Dec 31 04:21 engine-id
drwxrwxrwx  5 nobody nogroup     5 Dec 31 03:34 home
drwxrwxrwx  3 nobody nogroup     3 Oct 29  2023 image
drwxrwxrwx  3 nobody nogroup     3 Oct 29  2023 network
drwxrwxrwx 88 nobody nogroup    88 Dec 29 22:18 overlay2
drwxrwxrwx  8 nobody nogroup     9 Nov 28  2023 pi
drwxrwxrwx  4 nobody nogroup     4 Oct 29  2023 plugins
drwxrwxrwx  2 nobody nogroup     2 Dec 29 22:18 runtimes
drwxrwxrwx  2 nobody nogroup     2 Oct 29  2023 swarm
drwxrwxrwx  2 nobody nogroup     2 Dec 29 22:18 tmp
drwxrwxrwx  2 nobody nogroup     7 Dec 31 04:50 truenas_dietpi
drwxrwxrwx 24 nobody nogroup    25 Dec 29 22:18 volumes
dietpi@DietPi:~$

Thank you for your patience as I learn these things.

4

Everything seems to be assigned to user nobody and group nogroup. Probably something that comes from NFS of the NAS. It is best to look in your NAS to see if there are settings for NFS that can generate something like this.

5

First, thank you for your help. Here’s an update.

By checking the box “NFSv3 ownership model for NFSv4” in my TrueNAS server and restarting the service, all of the directories (except for .dietpi-sync.log) came under the ownership of truenas_dietpi

truenas_diepi is a user that I set up on both machines, so this is good. Unfortunately, I ran dietpi-sync again and still get the Invalid argument (22) for multiple chown lines.

I also found the user management link you posted in a different thread very helpful. This is what I wanted to learn. Thank you again.

Still digging, but wanted to post an update.

6

And another update.

  • Made sure that usernames and group GIDs were identical on both machines.
  • Mapall user and Mapall group on the TrueNAS server to the desired user/group

Now getting slightly different error, still on the chown/chgroup steps (last few lines):

rsync: [receiver] chown "/mnt/nfs_client/dietpi-sync/pi/unpoller/.unpoller.conf.GhZHMi" failed: Operation not permitted (1)
rsync: [receiver] chgrp "/mnt/nfs_client/dietpi-sync/truenas_dietpi/.bash_history.bgrTyd" failed: Operation not permitted (1)
rsync: [receiver] chgrp "/mnt/nfs_client/dietpi-sync/truenas_dietpi/.bash_logout.MIRwA4" failed: Operation not permitted (1)
rsync: [receiver] chgrp "/mnt/nfs_client/dietpi-sync/truenas_dietpi/.bashrc.b3BEAF" failed: Operation not permitted (1)
rsync: [receiver] chgrp "/mnt/nfs_client/dietpi-sync/truenas_dietpi/.profile.IGQYfA" failed: Operation not permitted (1)
rsync: [receiver] chgrp "/mnt/nfs_client/dietpi-sync/truenas_dietpi/.sudo_as_admin_successful.K9yOug" failed: Operation not permitted (1)
  1,065,280,708 100%   19.98MB/s    0:00:50 (xfr#886, to-chk=0/994)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7]

Any ideas on these errors?

7

There is no need to have a similar user an NAS side.

Anyway, there was another user having issues with TrueNas. At the end he fixed the issue by creating a new NFS share on NAS side Dietpi-backup errors when rsync reaches Perl folder - TrueNas NFS share · Issue #7320 · MichaIng/DietPi · GitHub

8

I have used Truenas with NFS for years and had this error several times, it was always something on the Truenas side of things. You would need to double check how you create and export your volumes that you are trying to share.

9

Tried a few more things, tested after each bullet point, still getting “[receiver] chown… Operation not permitted (1)” errors:

  • Deleted NFS share and recreated (both via GUI).
  • Deleted SMB share for same dataset after reading @Joulinar’s suggested link (though that one did have a different error)
  • Copied the entire directory I’m trying to sync over to the target (so that it would only have to sync the files, not create them). The copy worked. Syncing did not.
  • Set the ACL permissions for the target dataset in TrueNAS to everyone@ Full Control (was Modify)

Looking at the rsync documentation, there’s a way to tell it not to set ownership on the server (related post). Is there a way to set or pass this parameter on dietpi-sync? The dietpi-sync documentation was vague.

Any other thoughts?

Thank you again.

10

How did you copy them? cp -a with -a flag is needed to preserve all ownership and modes.

Usually indeed there does not need to exist a corresponding user/group on the server side, as the UID/GID is what is transferred, and what can be assigned without an actual user inheriting it. However, no idea what NFS share/settings TrueNAS applies. Which owner/group/mode do those failing files have on the client/DietPi side? The filename suffix is temporary, I guess, hence it is pi/unpoller/.unpoller.conf etc.

And are the files actually transferred, just owner/group/mode different, or are those files not transferred at all?

11

@MichaIng,

Interesting. Using the -a flag generates the “[receiver] chown… Operation not permitted (1)” error. I can successfully execute a copy command if I do not use that flag. What does that mean and how do I fix the issue?

12

It’s an issue on your NFS server side not allowing to change ownership. Most probably there you need to look for a solution.

1 Like
13

Right, a TrueNAS NFS server config issue. As long as this is the case, it is not suitable for Linux backups, as essential file modes are lost.

14

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.