seeking assistance for zfs allow settings

[ghost]

Hi everyone.

I think to use the zfs allow command to delegate permissions to a non-privileged user, on a per dataset basis, is the cleanest way to manage the permissions needed to run sanoid and syncoid. I, however, have problems figuring out which permissions I need to set in certain scenarios.

I would like to know which zfs commands are executed on sending a dataset to a target destination and receiving a dataset on the destination.

The piped command that syncoid outputs, when I don't have permissions for the transfer, seems to indicate that zfs receive is needed on the remote target. The man pages seem to indicate that I need zfs allow -u user receive,mount,create, refreservation pool/dataset to give all permissions for zfs receive to the target dataset. Unfortunately this seems not to be enough, because when I start a transfer with --no-privilege-elevation I get notifications about denied permissions.

I don't like to give more permissions than needed. Trial and error was unsuccessful for now. Any help is appreciated.

[lckarssen]

I am also in the process of figuring this out. So far, most of it seems to work with the following permissions for commands on the receiving side:

create,receive,destroy,rollback,snapshot,hold,release,mount

As I want to keep several properties as well (e.g. compression, recordsize, mountpoint), I also allow the following:

compression,snapdir,relatime,mountpoint,recordsize,sharenfs,sharesmb 

[ghost]

I think destroy could actually be a hard requirement. Definitely it is required if syncoid is user in combination with sanoid and its automatic snapshots. I wonder however why it is needed on an initial sync.

@lckarssen Do you know if the properties are needed if you want to use them or only if you want to change them? When syncoid creates a dataset it should inherit i.e. the compression property from its parent dataset or the pool itself. Do I need compression in any case or only if I want to change it?

[lckarssen]

From my experience, permissions for the properties are only needed if you explicitly send them, e.g. with -R or -p.

[bernecky]

So far, I am in the process of NOT figuring this out. I keep getting this on the sending side:

 BackupRustPoolOnMedusa smallpool/ds tempvol/ds
Copying zfs dataset smallpool/ds from boa to medusa
[email protected]'s password: 
merged snapshot list of tempvol/ds: 
$VAR1 = {
          'source' => {
                        'syncoid_boa_2021-12-14:14:40:53-GMT-05:00' => {
                                                                         'creation' => '1639510853000',
                                                                         'guid' => '14962200987962301575'
                                                                       }
                      }
        };



INFO: Sending oldest full snapshot smallpool/ds@syncoid_boa_2021-12-14:14:40:53-GMT-05:00 (~ 2.7 GB) to new target filesystem:
2.69GiB 0:00:46 [58.7MiB/s] [=======================================================>] 100%            
cannot mount '/tempvol/ds': failed to create mountpoint: Permission denied
CRITICAL ERROR:  zfs send  'smallpool/ds'@'syncoid_boa_2021-12-14:14:40:53-GMT-05:00' | pv -p -t -e -r -b -s 2868262032 | lz4  | mbuffer  -q -s 128k -m 16M 2>/dev/null | ssh     -S /tmp/[email protected] [email protected] ' mbuffer  -q -s 128k -m 16M 2>/dev/null | lz4 -dc |  zfs receive  -s -F '"'"'tempvol/ds'"'"'' failed: 256 at /usr/sbin/syncoid line 492.

Here is the script I am using, BackupRustPoolOnMedusa:

#!/usr/bin/bash
# Backup zfs dataset $1, on boa, to zfs dataset $2, on medusa
# E.g., 
#    BackupRustPoolOnMedusa smallpool/ds tempvol/ds
# NB. DOES NOT WORK ON FOLDERS - must be zfs dataset!
echo Copying zfs dataset $1 from boa to medusa
 /usr/sbin/syncoid  --dumpsnaps --recursive --compress=lz4  --no-privilege-elevation $1 [email protected]:$2

On the sending side, I have these zfs permissions:

send,snapshot,hold,mount,destroy On the receiving side, I have these permissions:

compression,mountpoint,create,mount,receive,rollback,destroy,hold,release,refreservation

It would be nice if the error messages were more precise. E.g., I can deduce from the zpool name that the "Permission denied" error happens on the receiving end, but it's not always that clear.

The need to do a receiving-end "zfs destroy -r tempvol/ds", after a failure, is irritating, but I'll live.

This is the initial dataset copy; I have not even attempted to get later snapshots across. So, I may be making an obvious error. I am a zfs newbie, too.

Both systems are recent Ubuntu 21.10 builds, and syncoid is new, too:

 syncoid --version
/usr/sbin/syncoid version 2.1.0
(Getopt::Long::GetOptions version 2.51; Perl version 5.32.1)

Now, having said all that, I find that ZFS and syncoid/sanoid are, in general, REALLY SLICK! Brilliant work, folks!

[0xFate]

Seemms to me rcv side lacks in permission to actually create the mountpoint for mounting the newly created dataset. Please disable automount in the parent dataset in rcv side or give the user pemission to do so in the target folder for verification

Robert Bernecky @.***> schrieb am Di., 14. Dez. 2021, 21:24:

So far, I am in the process of NOT figuring this out. I keep getting this on the sending side:

BackupRustPoolOnMedusa smallpool/ds tempvol/ds Copying zfs dataset smallpool/ds from boa to medusa @.***'s password: merged snapshot list of tempvol/ds: $VAR1 = { 'source' => { 'syncoid_boa_2021-12-14:14:40:53-GMT-05:00' => { 'creation' => '1639510853000', 'guid' => '14962200987962301575' } } };

INFO: Sending oldest full snapshot @._boa_2021-12-14:14:40:53-GMT-05:00 (~ 2.7 GB) to new target filesystem: 2.69GiB 0:00:46 [58.7MiB/s] [=======================================================>] 100% cannot mount '/tempvol/ds': failed to create mountpoint: Permission denied CRITICAL ERROR: zfs send 'smallpool/ds'@'syncoid_boa_2021-12-14:14:40:53-GMT-05:00' | pv -p -t -e -r -b -s 2868262032 | lz4 | mbuffer -q -s 128k -m 16M 2>/dev/null | ssh -S @. @.*** ' mbuffer -q -s 128k -m 16M 2>/dev/null | lz4 -dc | zfs receive -s -F '"'"'tempvol/ds'"'"'' failed: 256 at /usr/sbin/syncoid line 492.

Here is the script I am using, BackupRustPoolOnMedusa:

#!/usr/bin/bash

Backup zfs dataset $1, on boa, to zfs dataset $2, on medusa

E.g.,

BackupRustPoolOnMedusa smallpool/ds tempvol/ds

NB. DOES NOT WORK ON FOLDERS - must be zfs dataset!

echo Copying zfs dataset $1 from boa to medusa /usr/sbin/syncoid --dumpsnaps --recursive --compress=lz4 --no-privilege-elevation $1 @.***:$2

On the sending side, I have these zfs permissions:

send,snapshot,hold,mount,destroy On the receiving side, I have these permissions:

compression,mountpoint,create,mount,receive,rollback,destroy,hold,release,refreservation

It would be nice if the error messages were more precise. E.g., I can deduce from the zpool name that the "Permission denied" error happens on the receiving end, but it's not always that clear.

The need to do a receiving-end "zfs destroy -r tempvol/ds", after a failure, is irritating, but I'll live.

This is the initial dataset copy; I have not even attempted to get later snapshots across. So, I may be making an obvious error. I am a zfs newbie, too.

Both systems are recent Ubuntu 21.10 builds, and syncoid is new, too:

syncoid --version /usr/sbin/syncoid version 2.1.0 (Getopt::Long::GetOptions version 2.51; Perl version 5.32.1)

Now, having said all that, I find that ZFS and syncoid/sanoid are, in general, REALLY SLICK! Brilliant work, folks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jimsalterjrs/sanoid/issues/660#issuecomment-993951546, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYH7VDFSKTL6QB67UUPD3UQ6RYLANCNFSM5BCKEZQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bernecky]

Thank you, 0xFate.

Disabling automount works, but it entails some extra receiving-end pre- and post- work:

I did this on the receiving end:

sudo zfs set mountpoint=none tempvol

My sending-side script then ran to the completion, with success. I then had to do, on the receiving side:

sudo zfs set mountpoint=/tempvol tempvol

This is a start, but I think I am missing something, because all of the other examples I have seen appear to "just work".

BTW, I am not sure what you mean by what you mean by "...give the user permission...", but will look further on that front.

Thank you again for your time.

[0xFate]

What i mean are filesystem write permissions for the folder where the New datasets would get mounted after replication, by using sudo on zfs set mountpoint, zfs does actually 2 thing's as root, create a folder in target directory and then mount the dataset there.

Robert Bernecky @.***> schrieb am Di., 14. Dez. 2021, 22:32:

Thank you, 0xFate.

Disabling automount works, but it entails some extra receiving-end pre- and post- work:

I did this on the receiving end:

sudo zfs set mountpoint=none tempvol

My sending-side script then ran to the completion, with success. I then had to do, on the receiving side:

sudo zfs set mountpoint=/tempvol tempvol

This is a start, but I think I am missing something, because all of the other examples I have seen appear to "just work".

BTW, I am not sure what you mean by what you mean by "...give the user permission...", but will look further on that front.

Thank you again for your time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jimsalterjrs/sanoid/issues/660#issuecomment-994035917, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYH7SU7IWHPL2PFMFJXNLUQ6ZVTANCNFSM5BCKEZQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[0xFate]

On to the milage some people had solutions that "just worked", this depends all on your use case. For example, me would never run into that problem, because I would never need to access that data on the backup host directly, so I do not (auto)mount it. Your milage may vary, in IT it usually will... ;)

Jarek Nowak @.***> schrieb am Di., 14. Dez. 2021, 23:02:

What i mean are filesystem write permissions for the folder where the New datasets would get mounted after replication, by using sudo on zfs set mountpoint, zfs does actually 2 thing's as root, create a folder in target directory and then mount the dataset there.

Robert Bernecky @.***> schrieb am Di., 14. Dez. 2021, 22:32:

Thank you, 0xFate.

Disabling automount works, but it entails some extra receiving-end pre- and post- work:

I did this on the receiving end:

sudo zfs set mountpoint=none tempvol

My sending-side script then ran to the completion, with success. I then had to do, on the receiving side:

sudo zfs set mountpoint=/tempvol tempvol

This is a start, but I think I am missing something, because all of the other examples I have seen appear to "just work".

BTW, I am not sure what you mean by what you mean by "...give the user permission...", but will look further on that front.

Thank you again for your time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jimsalterjrs/sanoid/issues/660#issuecomment-994035917, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYH7SU7IWHPL2PFMFJXNLUQ6ZVTANCNFSM5BCKEZQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bernecky]

Thanks again for your assistance.

My Backup... script now runs without any problem, as far as I can tell. That is without requiring sudo. Moreover, the mountpoint for tempvol is back to /tempvol, although I recall leaving it set to none yesterday.

I had my systems shut down last night, so perhaps they just needed a rest, or the reboots untangled something.

Some FYI for others running into similar problems:

Sending system permissions for user rbe:

zfs allow smallpool
---- Permissions on smallpool ----------------------------------------
Local+Descendent permissions:
        user rbe destroy,hold,mount,send,snapshot

Receiving system permissions for user rbe:

---- Permissions on tempvol---------------------------------------- Local+Descendent permissions: user rbe compression,create,destroy,hold,mount,mountpoint,receive,refreservation,release,rollback,snapshot

I consider this issue closed.