Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

seeking assistance for zfs allow settings #660

Open
ghost opened this issue Jul 27, 2021 · 9 comments
Open

seeking assistance for zfs allow settings #660

ghost opened this issue Jul 27, 2021 · 9 comments

Comments

@ghost
Copy link

ghost commented Jul 27, 2021

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
Copy link

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
Copy link
Author

ghost commented Jul 27, 2021

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
Copy link

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

@lachesis lachesis mentioned this issue Aug 13, 2021
Closed
@bernecky
Copy link

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
rbe@medusa.local'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/syncoid-rbe@medusa.local-1639512227 rbe@medusa.local ' 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 rbe@medusa.local:$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
Copy link
Contributor

0xFate commented Dec 14, 2021 via email

@bernecky
Copy link

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
Copy link
Contributor

0xFate commented Dec 14, 2021 via email

@0xFate
Copy link
Contributor

0xFate commented Dec 14, 2021 via email

@bernecky
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lckarssen @0xFate @bernecky