How to access ZFS snapshots over SMB

[anodos]

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]

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]

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]

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.

 

[anodos]

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.

Okay. I don't see a problem with a symlink to it.

 

[anodos]

FYI, in FreeBSD 12 this becomes possible without the special auxiliary parameter for zfsacl.

 

[tobiasbp]

Great. Thanks. Symlink works well for us.

 

[hervon]

Works great. Thanks!

 

[diedrichg]

Wait?! So no more having to clone the snapshot to access the data?!

 

[Mr. Slumber]

This is really fantastic, thank you very much!!! :)

 

[Basil Hendroff]

Windows can access by navigating to \\<server>\<share>\.zfs\snapshot

Is there an overlap with shadow copies? Curious to know what makes this different?

 

[Heracles]

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]

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]

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,

 

[Redcoat]

Hope that helps you understand it better

Yes, thank you, I'll draw this up as I understand it and come back with questions if it's clear.

Thanks again.

 

[anodos]

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]

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]

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]

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]

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/