Closed tdb85 closed 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.
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.
Trivial indeed...just did it (though this is very much a version 0.000001 script).
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
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.
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
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.
Now you have me curious about it, though!
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.
Please update me if you ever do get this working.
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.
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.
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. =)
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...
Check out #142
Does that help?
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
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.
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.
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.
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?
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
Are you showing any errors in the log?
What about this setting: acl_xattr:ignore system acls = no
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.
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
Have you confirmed that you can access the snapshots manually, through the .zfs/snapshot directory?
That's interesting - I cannot. \\server\backup\.zfs\snapshot\
doesn't work on this machine (but does on my FreeNAS box)
Hmmm.
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.
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. :-(
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?
Not sure. Can you access the .zfs directories from a Linux Shell?
Yes - definitely there in a terminal.
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.
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).
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.
@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).
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!
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
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.
@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.
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:
autosnap_daily_2021-12-07_01-15-00
.
_
didn't work, as this occurs more than once in the snapshot name (having a proper snapprefix defined didn't help)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>
@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?
- 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.
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.
I realized I didn't use this variable:
shadow: mountpoint = /srv/zfs
I have commented that out in the meantime and it still works.
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
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.