jimsalterjrs / sanoid

These are policy-driven snapshot management and replication tools which use OpenZFS for underlying next-gen storage. (Btrfs support plans are shelved unless and until btrfs becomes reliable.)
http://www.openoid.net/products/
GNU General Public License v3.0
3.12k stars 306 forks source link

Integrate with Samba snapdir? #5

Closed tdb85 closed 9 years ago

tdb85 commented 9 years ago

Has anybody attempted to use sanoid with Samba's vfs_shadow_copy2 module?

It doesn't appear I'd be able to set "shadow:format" to any format which would match sanoid's snapshots. I've also found no obvious way to tell sanoid how to configure the date format.

 NAME                                                     USED  AVAIL  REFER  MOUNTPOINT
 zroot/data/shared@autosnap_2015-03-17_10:34:09_hourly       0      -   817G  -
 zroot/data/shared@autosnap_2015-03-17_10:34:09_monthly      0      -   817G  -
 zroot/data/shared@autosnap_2015-03-17_10:34:09_daily        0      -   817G  -
jimsalterjrs commented 9 years ago

It doesn't appear I'd be able to set "shadow:format" to any format which would match sanoid's snapshots.

I think you can; but if str[fp]time doesn't support wildcards (and I don't think it does), you're stuck with needing to pick a given snapshot type (hourly, daily, monthly) rather than exposing all of them - at least, without actually mounting the snapshots as clones somewhere. I'm pretty sure str[fp]time supports inserting arbitrary constant values just fine, which would leave you with something like autosnap-%Y-%m-%d_%H:%M:%S_daily if you wanted to expose the dailies.

It might be worth reaching out to the Samba team to see if there's any possibility of adding regex capabilities to vfs_shadow_copy2's parser.

Alternately, you could automatically mount clones of the snapshots in any format desired, and use vfs_shadow_copy2 to look at the clones rather than at the raw snapshots in the .zfs/snapshot/ directory.

I've looked longingly at dispensing with the snapshot suffix - hourly, daily, etc - but without it, I've balked at the complexity of accurately detecting which snapshots can and can't be thinned by policy to match retention at those levels.

jimsalterjrs commented 9 years ago

Alternately, it might be easier to do exactly what the author of the module says you don't need to:

You don't need to populate your shares with symlinks to the snapshots. This can be very important when you have thousands of shares, or use [homes].

Just keeping a special directory that contains symlinks to the snapshots in the format desired by vfs_shadow_copy2 would be pretty trivial.

tdb85 commented 9 years ago

Trivial indeed...just did it (though this is very much a version 0.000001 script).

http://pastebin.com/WfdWnivv

Although I haven't been successful in actually seeing the previous versions in Windows yet, this is definitely a step in a working direction for me to get the functionality I desire.

root@whimsy:/shared/.shadow_snapshots # ls -l
total 6
lrwxr-xr-x  1 root  browngrp    58 Mar 17 11:57 2015-03-17_10:34:09 -> /shared/.zfs/snapshot/autosnap_2015-03-17_10:34:09_monthly
lrwxr-xr-x  1 root  browngrp    57 Mar 17 11:57 2015-03-17_11:00:00 -> /shared/.zfs/snapshot/autosnap_2015-03-17_11:00:00_hourly
-rwxr-xr-x  1 root  browngrp  1710 Mar 17 11:57 build_snapdir
jimsalterjrs commented 9 years ago

You don't have the GMT in there that the default format is expecting. Probably why you haven't been successful in populating them in Explorer yet.

Try renaming those to GMT-2015-03-17_10:34:09 and GMT-2015-03-17_11:00:00 and see if you have any luck.

tdb85 commented 9 years ago

I've set the format explicitly in smb.conf...the relevant block below. I haven't played around with it much yet or checked the logs to see what's happening. It could be even something on my Windows machine needing a reboot which I can't do right now.

[shared]
    path = /shared
    force group = browngrp
    read only = No
    create mask = 0664
    directory mask = 0775
    vfs objects = zfsacl, shadow_copy2
    shadow:sort = desc
    shadow:format = "%Y-%m-%d_%H:%M:%S"
    shadow:localtime = yes
    shadow:basedir = /shared
    shadow:snapdir = /shared/.shadow_snapshots
    nfs4:chwon = yes
    nfs4:acedup = merge
    nfs4:mode = special
jimsalterjrs commented 9 years ago

Yeah, I dunno - short of doing a FreeNAS install and scrutinizing its configs, I wouldn't know where to go specifically, I've never used that module.

jimsalterjrs commented 9 years ago

Now you have me curious about it, though!

jimsalterjrs commented 9 years ago

Doing some testing and some Googling. I'm not 100% certain this module is actually working in most distribution versions of Samba. Seeing a whoooole lot of "can't get this working" and very little in the way of success stories - those usually coming from people who patched and recompiled Samba sources from scratch.

jimsalterjrs commented 9 years ago

Please update me if you ever do get this working.

tdb85 commented 9 years ago

Will do. I haven't spent a lot of time getting it going yet. This is a home server but I'd like to employ this method and sanoid at work in the near future. We're using Solaris 11, and I'm using FreeBSD so things will be slightly different anyway.

I wasn't aware FreeNAS did this. I'll have to spin up a VM and see what the smb.conf & zfs snapshots look like.

jimsalterjrs commented 9 years ago

FreeNAS and NAS4Free both do this to some extent.

FreeNAS is far and away better at it, though.

There is a distinct possibility that FreeNAS is using non-standard Samba binaries. They break pretty bleeding edge. But yeah, that (dissecting their configs) is not a bad idea at all.

On 03/17/2015 03:06 PM, Teddy Brown wrote:

Will do. I haven't spent a lot of time getting it going yet. This is a home server but I'd like to employ this method and sanoid at work in the near future. We're using Solaris 11, and I'm using FreeBSD so things will be slightly different anyway.

I wasn't aware FreeNAS did this. I'll have to spin up a VM and see what the smb.conf & zfs snapshots look like.

— Reply to this email directly or view it on GitHub https://github.com/jimsalterjrs/sanoid/issues/5#issuecomment-82536863.

jimsalterjrs commented 9 years ago

I'm going to close this for now because it's a bit out of scope, and (more importantly) because this feature appears to be broken in most distro packages of Samba anyway. I'm certainly open to reopening it at a later date, though, especially if production versions of Samba start actually supporting vfs_shadowcopy2!

@goteddygo I am still very interested in your progress with this, please keep me in the loop. =)

MAP-admin-one-bee commented 3 years ago

Any chance of resurrecting this discussion?

Taking a look at a running FreeNAS unit I have, it's using shadow_copy_zfs not 2, so I don't think that's much help.

For my usage, exposing just one of daily or hourly or weekly is probably good...

gnordli commented 3 years ago

Check out #142

Does that help?

MAP-admin-one-bee commented 3 years ago

It looks like it should help. Haven't gotten it to work yet though.

Do the snapshots have to be visible for samba to share them? or any other gotchas past adding those five lines to smb.conf?

        vfs objects = shadow_copy2
        shadow: delimiter = _
        shadow: snapprefix = ^autosnap
        shadow: format = _%Y-%m-%d_%H:%M:%S_
        shadow: sort = desc
        shadow: snapdir = .zfs/snapshot

The snapshots do follow that template as far as I can see - just the stock set up e.g. /tank/redacted/.zfs/snapshot/autosnap_2020-11-19_19:00:01_hourly

lckarssen commented 3 years ago

On Ubuntu 20.04 (with shadow_copy2) I have the following working smb.conf configuration. This is in [global]:

        shadow:localtime = no
        shadow:delimiter = _
        shadow:snapprefix = ^autosnap
        shadow:format = _%Y-%m-%d_%H:%M:%S
        shadow:sort = desc
        shadow:snapdir = .zfs/snapshot
        vfs objects = catia acl_xattr

In the share-specific section I have

        vfs objects = shadow_copy2

The ZFS snapdir option is set to visible for that dataset. Not sure if it is required.

gnordli commented 3 years ago

Another note:

I need to set this to get it to work:

acl_xattr:ignore system acls = no.

When set to yes, a best effort mapping from/to the POSIX ACL layer will not be done by this module. The default is no, which means that Samba keeps setting and evaluating both the system ACLs and the NT ACLs. This is better if you need your system ACLs be set for local or NFS file access, too. If you only access the data via Samba you might set this to yes to achieve better NT ACL compatibility.

secabeen commented 3 years ago

I've run into some issues with this in the past because without the best-effort mapping there are no NT ACLS for the .zfs and .zfs/snapshot directories, which blocks access to the folders.

--Ted

On 11/19/2020 2:05 PM, gnordli wrote:

Another note:

I need to set this to get it to work:

acl_xattr:ignore system acls = no.

When set to yes, a best effort mapping from/to the POSIX ACL layer will not be done by this module. The default is no, which means that Samba keeps setting and evaluating both the system ACLs and the NT ACLs. This is better if you need your system ACLs be set for local or NFS file access, too. If you only access the data via Samba you might set this to yes to achieve better NT ACL compatibility.

— 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/5#issuecomment-730666253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQNRG54QSXBDG3YQCMIXITSQWJD7ANCNFSM4A6ADY3A.

MAP-admin-one-bee commented 3 years ago

Well, I'm stumped.

Looking at notes here and elsewhere, I've tried

It's Samba 4.10 on CentOS 7

Is there a way to get more logging so I can maybe spot something? or other suggestions on what I could try?

MAP-admin-one-bee commented 3 years ago

For the record - current settings are

[backup]
        comment = Shared Backup Folder
        path = /tank/backup
        public = no
        writable = yes
        guest ok = no
        valid users = @"Domain Users@example.com"
        vfs objects = shadow_copy2 acl_xattr
        acl_xattr:ignore system acls = yes
        shadow: snapdir = .zfs/snapshot
        shadow: sort = desc
        shadow: format = _%Y-%m-%d_%H:%M:%S
        shadow: delimeter = _
        shadow: snapprefix = ^autosnap
        shadow: localtime = no
gnordli commented 3 years ago

Are you showing any errors in the log?

What about this setting: acl_xattr:ignore system acls = no

MAP-admin-one-bee commented 3 years ago

Thanks for the suggestions.

No errors in the log. I actually deliberately introduced a typo to make sure it was logging errors and reversed it.

And setting that yes or no made no difference.

gnordli commented 3 years ago

I am on Samba 4.11 (Ubuntu 20.04).

I wonder if there are issues with the 4.10 version. I know there were some versions that had problems with it, just not sure what they were.

One other setting I have that is different than yours:

acl_xattr:default acl style = windows

secabeen commented 3 years ago

Have you confirmed that you can access the snapshots manually, through the .zfs/snapshot directory?

MAP-admin-one-bee commented 3 years ago

That's interesting - I cannot. \\server\backup\.zfs\snapshot\ doesn't work on this machine (but does on my FreeNAS box)

Hmmm.

secabeen commented 3 years ago

This may be the bug I've run into. With:

   acl_xattr:ignore system acls = yes

Samba just uses the Windows ACLS stored in the xattr. It ignores the posix mode-based perms. However, when creating the virtual .zfs and .zfs/snapshot directories (which don't have actual directories backing them), ZFS creates simulated posix permissions, but does not create an equivalent "All Users Read and Execute" Windows ACL. (There's no NTACL.Security xattr defined at all on .zfs or .zfs/snapshot.) Thus, Samba doesn't allow access to those directories or their children. I've opened a bug with ZFS to put that in, but it hasn't gotten any traction. The workaround is to set acl_xattr:ignore system acls = no, so that Samba will allow access based on the posix mode, but then that access is allowed throughout the share, which is less ideal.

MAP-admin-one-bee commented 3 years ago

Well, if I change to this

[backup]
        comment = Shared Backup Folder
        path = /tank/backup
        public = no
        writable = yes
        guest ok = no
        valid users = @"Domain Users@example.com"
        vfs objects = shadow_copy2 acl_xattr
        set acl_xattr:ignore system acls = no
        shadow: snapdir = .zfs/snapshot
        shadow: sort = desc
        shadow: format = _%Y-%m-%d_%H:%M:%S
        shadow: delimeter = _
        shadow: snapprefix = ^autosnap
        shadow: localtime = no

I still can't access \\server\backup\.zfs which I think you're telling me should work, but if it did work, it would make windows attributes not work on the regular parts share too, which isn't good.

This is turning into a bit of a quagmire. :-(

MAP-admin-one-bee commented 3 years ago

That does imply that even switching to a different auto snapshot system still wouldn't work? Why then do other people seem to make it work? Are they not using windows based extended attributes just unix rwx?

secabeen commented 3 years ago

Not sure. Can you access the .zfs directories from a Linux Shell?

MAP-admin-one-bee commented 3 years ago

Yes - definitely there in a terminal.

secabeen commented 3 years ago

next step is probably to turn up the samba debugging and try to access the .zfs and .zfs/snapshot directories and see what logs/errors Samba throws on that attempted access.

Also make sure you've restarted any smbd processes lying around, in case they haven't seen the update(s) you're making to your smb.conf.

MAP-admin-one-bee commented 3 years ago

Well, I haven't completely quit on this yet.

I figured out I had to manually chcon -t samba_share_t .zfs .zfs/snapshot to get the snapshot folders to be visible via samba.

Now the titles are gibberish (probably because of the colon in the file names).

MAP-admin-one-bee commented 3 years ago

More frustration. I can use either vfs_catia or (vfs_catia and vfs_fruit) to make the file names with colons readable under Windows. I kinda like the fruit option, we have some Macs floating around.

But I still can't get the snapshots to show up under previous versions.

phreaker0 commented 3 years ago

@MAP-admin-one-bee we use the previous versions stuff with Debian Buster (samba Version 4.9.5-Debian) and the following configuration:

vfs objects = full_audit, shadow_copy2, catia
nt acl support = no
acl map full control = True
mangled names = no
catia:mappings = 0x22:0xa8,0x2a:0xa4,0x2f:0xf8,0x3a:0xf7,0x3c:0xab,0x3e:0xbb,0x3f:0xbf,0x5c:0xff,0x7c:0xa6
shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = autosnap_%Y-%m-%d_%H:%M:%S_hourly

users can use the windows previous versions feature (only hourly snapshots) or can access the .zfs/snapshots/ directory directly (not visible) directly with windows,macos or linux. We tried to use the frequently snapshots but in this case there was some timeout in samba and previous versions didn't work (we have ~1200 frequently snapshots and ~350 hourly snapshots).

MAP-admin-one-bee commented 3 years ago

Good news and bad news. Good news - it's working! Yay! Bad news - I don't know why....

I started by taking the config above from @phreaker0 (Thanks!) and plugged it right in, and it worked.

So then I started adding back the things I had picked earlier, and it kept working :-/

This configuration is what I have right now, and it works.

[backup]
        comment = Shared Backup Folder
        path = /tank/backup
        public = no
        writable = yes
        guest ok = no
        valid users = @"Domain Users@example.com"
        vfs objects = catia fruit streams_xattr acl_xattr shadow_copy2
        fruit:resource = file
        fruit:metadata = netatalk
        fruit:locking = netatalk
        fruit:encoding = native
        acl_xattr:default acl style = windows
        shadow: snapdir = .zfs/snapshot
        shadow: sort = desc
        shadow: format = autosnap_%Y-%m-%d_%H:%M:%S_hourly

It also works if I swap daily in for hourly.

Guesses - this simplified way of specifying snapshot names is part of what helped

So I'll sneak away quietly and hope to never touch this again. Hope this mess helps someone else figure it out in future.

Big thank you to all of you that kicked in your comments!

CvH commented 3 years ago

just for the record, I needed to add acl_xattr:default acl style = windows otherwise it was not working at Ubuntu 20.04

works

  # Windows ACL
  vfs objects = acl_xattr shadow_copy2

  # Ubuntu 20.04 
  acl_xattr:default acl style = windows

  shadow: snapdir = /backup/.zfs/snapshot
  shadow: sort = desc
  shadow: snapprefix = ^autosnap
  shadow: format = _%Y-%m-%d_%H:%M:%S
  shadow: delimiter = _

Both works, but without the acl_xattr:default acl style = windows the regex is not working and I need to set the format

  # Windows ACL
  vfs objects = acl_xattr shadow_copy2

  shadow: snapdir = /backup/.zfs/snapshot
  shadow: sort = desc
  shadow: format = autosnap_%Y-%m-%d_%H:%M:%S_daily
ovizii commented 3 years ago

If I may resurrect this old thread but I need some help.

This got me going:

shadow:snapdir = .zfs/snapshot
shadow:sort = desc
shadow:format = _%Y-%m-%d_%H:%M:%S
shadow: snapprefix = ^autosnap
shadow: delimiter = _
shadow: localtime = no

it works for the share: Documents, I can see snapshots via Win10 restore previous versions.

It doesn't work for another share named Pictures though.

Both do have snapshots (mostly empty due to automation):

 zfs list |grep -v docker | grep Documents
sixer/Documents@autosnap_2021-06-14_00:30:00_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_00:45:01_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_01:00:00_hourly                                              0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_01:00:00_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_01:15:01_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_01:30:00_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_01:45:00_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_02:00:01_hourly                                              0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_02:00:01_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_02:15:00_frequently                                          0B      -     30.3G  -
sixer/Documents@autosnap_2021-06-14_02:30:00_frequently                                          0B      -     30.3G  -
zfs list |grep -v docker | grep Pictures
sixer/Pictures@autosnap_2020-03-04_19:45:00_yearly                                               0B      -      333G  -
sixer/Pictures@autosnap_2020-07-01_00:00:00_monthly                                              0B      -      333G  -
sixer/Pictures@autosnap_2020-08-01_00:00:00_monthly                                              0B      -      333G  -
sixer/Pictures@autosnap_2020-09-01_00:00:00_monthly                                              0B      -      333G  -
sixer/Pictures@autosnap_2020-10-01_00:00:00_monthly                                              0B      -      333G  -
sixer/Pictures@autosnap_2020-11-01_00:00:00_monthly                                              0B      -      333G  -
sixer/Pictures@autosnap_2020-12-01_00:00:01_monthly                                              0B      -      339G  -
sixer/Pictures@autosnap_2021-01-18_10:45:06_yearly                                               0B      -      339G  -
sixer/Pictures@autosnap_2021-01-18_10:45:06_monthly                                              0B      -      339G  -

and on top of that, if I do a ls -al /sixer/Documents/.zfs/snapshots I see some snapshots owned by root and some by the actual user of the /sixer/Documents folder - so obviously the root-owned ones are not accessible via "restore previous versions" as the share is accessed by the owner of the shared folder and not by root.

Alestrix commented 2 years ago

@ovizii Are you sharing all of /sixter in smb.conf or /sixter/Documents and /sixter/Pictures separately? If it's the former, you might want to try shadow: snapdirseverywhere = yes as your .zfs directory is not a direct child of /sixter.

Alestrix commented 2 years ago

I think I tried all of the configuration examples here and none of them worked for me. What I had to do to make it work:

So this is what worked for me in the end:

[storage]
        path = /srv/zfs
        browseable = yes
        read only = no
        guest ok = no

        vfs objects = shadow_copy2
        shadow: mountpoint = /srv/zfs
        shadow: snapdir = .zfs/snapshot
        shadow: snapdirseverywhere = yes
        shadow: sort = desc
        shadow: format = ly_%Y-%m-%d_%H-%M-%S
        shadow: snapprefix = ^autosnap_\(frequent\)\{0,1\}\(hour\)\{0,1\}\(dai\)\{0,1\}\(month\)\{0,1\}\(week\)\{0,1\}
        shadow: delimiter = ly_
        shadow: localtime = no

Not all of these settings might be needed (maybe mountpoint can go), but I didn't feel like keep on tinkering after it finally worked after several hours of trying. I needed snapdirseverywhere as I have zfs (sub-)volumes under the share root.

PS: <rant> I still can't fathom why the shadow_copy2 man page doesn't state that the delimiter needs to be repeated in the format specification. This is completely counter-intuitive and -- given the meaning of the word "delimiter" -- syntactically incorrect. </rant>

ovizii commented 2 years ago

@Alestrix thanks for your feedback! I will try and replicate your success in the next few days, I had given up on this subject.

I do share /sixter/Documents and /sixter/Pictures and a few others separately.

I realized I didn't use this variable: shadow: mountpoint = /srv/zfs - I used my settings as global variables but looking at your example I think I need to set this one for each share and the other ones as global. I will report back once I get around to test it.

Here is the most important question: If you check i.e. if I do a ls -al /srv/zfs/.zfs/snapshots who owns your screenshots?

Mine are owned by root - is that the same for you?

ovizii commented 2 years ago
  • Edited sanoid code so that snapshot format is akin to autosnap_daily_2021-12-07_01-15-00.

I just realized I have no idea how to do this, any pointers? I thought it might be a setting somewhere but can't find it right now.

Alestrix commented 2 years ago

I just realized I have no idea how to do this, any pointers? I thought it might be a setting somewhere but can't find it right now.

It was actually a pretty minor change - though I admit I might have missed something. The code is working well for snapshot creation and it should work for purging, but the latter isn't really tested yet.

I just forked the repo and uploaded my changes in my fork. You can see the changes here: https://github.com/Alestrix/sanoid/commit/0c0566f26ae4586639b904dfad20d109f1ed0754#diff-833d7ceafcf35667b591fa806255c9a3771ed52f59afb1462788c28dd74499aa

EDIT: Just checked my "frequently" snapshots and they are being purged properly. Cannot test the other types as their purging time hasn't arrived yet, but if "frequently" works, so should the others.

Alestrix commented 2 years ago

I realized I didn't use this variable: shadow: mountpoint = /srv/zfs

I have commented that out in the meantime and it still works.

exscape commented 1 year ago

This took me hours to get working, and I couldn't quite get it working with the help above (and I looked in many other places, too), so what's worked for ME is shown below.

First, a helpful tip for testing this: right-click a folder in Windows and check properties. Files say "There are no previous versions available" unless you have actually changed that file since taking the snapshots. Folders seem to always show all existing snapshots.
This probably means I had it working at some point earlier but didn't realize as I was testing on unmodified files.

I use unmodified sanoid 2.1.0 on Debian, with Samba (also unmodified) 4.17.10.
I take hourly and daily snapshots on all datasets, and additionally weekly+monthly on some.

Since it seems a massive pain to use more than one snapshot type without switching from sanoid, I decided to use daily snapshots.

I made no changes to smb.conf outside of the share section, i.e. my global section is untouched.

I do have one issue left that I won't bother with, at least not now: the times shown in Windows are incorrect, as the snapshots ARE in local time, but if I set localtime = yes I always get "No previous versions available". No idea why, looking at the source code for vfs_shadow_copy2 the differences when localtime is used are minimal.

Edit: Um, OK -- localtime = yes works now... I'm completely certain the exact same config didn't work literally 10 minutes ago.

Here's my Samba config:


[Laniakea]
        comment = Laniakea
        path = /laniakea
        browsable = yes
        guest ok = no
        read only = no
        create mask = 0755
        valid users = @serenity

        vfs objects = shadow_copy2
        shadow: mountpoint = /laniakea
        shadow: snapdir = .zfs/snapshot
        shadow: snapdirseverywhere = yes
        shadow: sort = desc
        shadow: format = autosnap_%Y-%m-%d_%H:%M:%S_daily
        # This line is crucial for some reason, snapshots are not found with localtime = yes!
        shadow: localtime = no