Rsync tasks 'operation not permitted' - how can root be refused anything ?

AlcSi

Dabbler
Joined
Sep 20, 2019
Messages
41
The question can seem naive, because it is... ;)

I have 2 FreeNAS, NAS-A, and NAS-B which replicates everything everynight from NAS-A.

It uses rsync tasks on NAS-B, with the 'root' user.
As passwords are the same (or is it because I have setup ssh with RSA via cli ?), it runs without user input.

I get the famous 'operation not permitted' that was already discussed elsewhere, and for which the given solution was to add " -A --no-perms" to the rsync tasks options.

It works, more or less, because it leaves a few minor errors, with no impact on replication afaik, but in the end it's ok.

Now my question is really theoretical, as in title : how can a task run by root be refused anything ?
Should I be running the task with the rights from the original volume on NAS-A, or with rights from the destination volume ? (root is neither user or group there)
Should I add root to every group ?

Sorry I know this looks lazy but I'm at a loss here.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
The question can seem naive, because it is... ;)

I have 2 FreeNAS, NAS-A, and NAS-B which replicates everything everynight from NAS-A.

It uses rsync tasks on NAS-B, with the 'root' user.
As passwords are the same (or is it because I have setup ssh with RSA via cli ?), it runs without user input.

I get the famous 'operation not permitted' that was already discussed elsewhere, and for which the given solution was to add " -A --no-perms" to the rsync tasks options.

It works, more or less, because it leaves a few minor errors, with no impact on replication afaik, but in the end it's ok.

Now my question is really theoretical, as in title : how can a task run by root be refused anything ?
Should I be running the task with the rights from the original volume on NAS-A, or with rights from the destination volume ? (root is neither user or group there)
Should I add root to every group ?

Sorry I know this looks lazy but I'm at a loss here.
It's the ZFS aclmode property on the dataset. Your dataset is explicitly configured to return EPERM on chmod requests. This is set by default on "windows" datasets underlying an SMB share. You should probably be using ZFS replication rather than rsync in this case. In general -no-perms should probably be used if the source has extended ACL entries defined since rsync only has support for POSIX1e ACLs.
 
Top