Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

How to access ZFS snapshots over SMB

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,646
Starting in 11.1-U5 we added some knobs to expose ZFS snapshots over SMB. You can enable by setting the following auxiliary parameters to your SMB shares:
Code:
zfsacl:expose_snapdir=True
veto files = /.windows/.mac/


Then restart samba. The ZFS dataset still has the "snapdir=hidden" property set so you'll have to type in the full UNC path to the snapshot directory. Macs can mount with the following string: smb://<server>/<share>/.zfs/snapshot
Windows can access by navigating to \\<server>\<share>\.zfs\snapshot

You can do the same with Linux mounts if needed.

Hope you all find this useful.
 

tobiasbp

FreeNAS Experienced
Joined
Dec 2, 2015
Messages
224
This is a killer feature for us. Thank you @anodos

Is there a downside to creating a link in the root of the dataset to .zfs./snapshot to make the users see the dir in the root?
 

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,646
This is a killer feature for us. Thank you @anodos

Is there a downside to creating a link in the root of the dataset to .zfs./snapshot to make the users see the dir in the root?
You can actually change the snapdir visibilty by running the command zfs set snapdir = visible <pool>/<dataset>
 

tobiasbp

FreeNAS Experienced
Joined
Dec 2, 2015
Messages
224
You can actually change the snapdir visibilty by running the command zfs set snapdir = visible <pool>/<dataset>
That is what I did, but ".zfs" is hidden in the MacOS Finder. Hence, I was thinking about creating the (visible) link to help out the users.
 

hervon

FreeNAS Experienced
Joined
Apr 23, 2012
Messages
230
Works great. Thanks!
 

diedrichg

FreeNAS Expert
Joined
Dec 4, 2012
Messages
1,212
Wait?! So no more having to clone the snapshot to access the data?!
 

Mr. Slumber

FreeNAS Experienced
Joined
Mar 10, 2019
Messages
145
This is really fantastic, thank you very much!!! :)
 

Seymour Butt

FreeNAS Experienced
Joined
Jan 4, 2014
Messages
453

Heracles

FreeNAS Guru
Joined
Feb 2, 2018
Messages
422
Hi guys,

Know that there is a risk to expose your snapshot to users : they can destroy them now...

A snapshot is a great way to protect data against users' error and incidents like accidental delete, ransomware, etc. If you expose your snapshots to your clients, your clients may now affect them.

Here, I created a subdir NFSRoot as a first subfolder in my dataset and it is this from this one that I share. I did that precisely to avoid exposing a path leading to the snapshots.

So what do you use snapshots for ? If you use them as a protection against anything coming from the clients, then you should not expose them to clients. If you are using them as a service offered to clients for versioning, then expose them. Just know that you can not have it all : protected against the client and exposed to them at the same time...
 

Redcoat

FreeNAS Expert
Joined
Feb 18, 2014
Messages
1,217
Here, I created a subdir NFSRoot as a first subfolder in my dataset and it is this from this one that I share. I did that precisely to avoid exposing a path leading to the snapshots.
Can you explain that, please? I'm uncertain what you are describing.
 

Heracles

FreeNAS Guru
Joined
Feb 2, 2018
Messages
422
Hi Redcoat,

In my pool, at the root, I have a few datasets : HAStore, LocalStore ESXStore. HAStore is replicated to my DR FreeNAS while the 2 others are not. ESXStore is for my ESXi server and LocalStore is for everything else.

Inside my HAStore, I created a dataset for my Nextcloud server. For security reason, I want to be sure that no incident in the Nextcloud server can affect the snapshots. So to put them out of reach, I created :
/mnt/pool/HAStore/Nextcloud/NFSRoot
and it is that folder that is shared over NFS to the Nextcloud server running in an external VM, without the possibility to mount anything else,

Should the Nextcloud VM turns bad, it can do whatever inside that NFSRoot folder, but can not go any higher in the path. Thanks to that, it can not access /mnt/pool/HAStore/Nextcloud/.zfs

So it can not access the snapshots.

That is how I ensure the snapshots will not be touched, so can be an effective security mechanism against client-side incidents.

Hope that helps you understand it better,
 

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,646
Is there an overlap with shadow copies? Curious to know what makes this different?
For shadow copy support windows clients send a special query to the server asking for a list of previous versions. Once it has this list and you browse to a previous version, the file name coming over the wire has an @GMT prefix. vfs_shadow_copy2 generates the list of previous versions and translates the received @GMT string to a path in the hidden .zfs/snapshot/ directory. In the end, both methods of accessing previous versions of files does basically the same thing, but shadow_copy2 has some intermediate steps.
 

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,646
Hi guys,

Know that there is a risk to expose your snapshot to users : they can destroy them now...

A snapshot is a great way to protect data against users' error and incidents like accidental delete, ransomware, etc. If you expose your snapshots to your clients, your clients may now affect them.

Here, I created a subdir NFSRoot as a first subfolder in my dataset and it is this from this one that I share. I did that precisely to avoid exposing a path leading to the snapshots.

So what do you use snapshots for ? If you use them as a protection against anything coming from the clients, then you should not expose them to clients. If you are using them as a service offered to clients for versioning, then expose them. Just know that you can not have it all : protected against the client and exposed to them at the same time...
It is not possible for users to delete snapshots. They are readonly.
 

seanm

FreeNAS Experienced
Joined
Jun 11, 2018
Messages
342
zfsacl:expose_snapdir=True veto files = /.windows/.mac/
Why the latter setting? Is it because 'veto files' contains '.snapshot' and '.zfs' by default and so you have to set something else to un-veto them?

Anyway, this is quite nice for macOS clients, where 'shadow copies' are unsupported (as best as I can tell)
 

anodos

Belly-button Lint Extraordinaire
iXsystems
Joined
Mar 6, 2014
Messages
5,646
Why the latter setting? Is it because 'veto files' contains '.snapshot' and '.zfs' by default and so you have to set something else to un-veto them?

Anyway, this is quite nice for macOS clients, where 'shadow copies' are unsupported (as best as I can tell)
Yes. Current versions of FreeNAS use ".mac" and ".windows" files to indicate that they are configured in this way. I plan to do away with that entirely soon. (Maybe sneak it into 11.3). We're planning to have a proper ACL editor in soon anyway, which will eliminate the primary need to distinguish between them.
 

seanm

FreeNAS Experienced
Joined
Jun 11, 2018
Messages
342
That is what I did, but ".zfs" is hidden in the MacOS Finder. Hence, I was thinking about creating the (visible) link to help out the users.
Another option (probably less good), is to use Finder's Go > Go To Folder command and type in /Volumes/<ShareName>/.zfs/snapshot/
 
Top