samba - Mar 2022 - ZFS and vfs_shadow_copy2

On 17/02/2022 14:54, Andrea Venturoli via samba wrote:
> 
> Hello.
> 
> I'm trying the above combination (on FreeBSD).
> 
> Relevant part of my smb.conf is:
> 
>  ??????? vfs objects=full_audit shadow_copy2
>  ??????? shadow:sort = desc
>  ??????? shadow:format=-%Y%m%d%H%M%S
>  ??????? shadow:delimiter=-
>  ??????? shadow:snapprefix=auto_zroot
>  ??????? shadow:localtime=yes
>  ??????? shadow:snapdir=.zfs/snapshot
I'm running Samba 4.13.17 as provided by the default Ubuntu 20.04 
repositories, and have a slightly simpler set of options because my 
snapshot names are just unix timestamps:

         shadow:sort = desc
         shadow:snapdir = .zfs/snapshot
         shadow:format = %s
         shadow:localtime = yes

However, I wonder if you need the leading "-" in your shadow:format.
I'd
have guessed that samba will look for dirs named:

$(SNAPPREFIX)$(DELIMITER)$(FORMAT)

which would lead to two "-"s , whereas your snapshots just have one.

I've tcpdumped on the samba server at the point I right click the 
"Restore previous versions.." option on my Win10 client, and then
viewed
the pcap in wireshark. I see my client sending a 
FSCTL_SRV_ENUMERATE_SNAPSHOTS request, and then in the server reply I 
look at the "Ioctl Response" part of the smb payload. That response 
includes "Out data" looking like...

Number of snapshots: 19
Snapshot: @GMT-2022.02.17-12.54.03
Snapshot: @GMT-2022.02.17-06.54.03
(etc etc)

The list of snapshots in the pcap matches what I expect based on running 
zfs list -r -t snapshot -oname, and all of the snapshots display as 
expected in the Windows previous version client. (NB I have seen some 
times when the contents of a .zfs/snapshot directory did not match the 
actual list of snapshots reported by zfs list and never managed to find 
out why - but that was quite a few years and OSs and ZFS versions ago!)

Thus, a similar tcpdump might give you an idea as to whether your samba 
set up is not responding with the right list of snapshots, or if the 
fault lies with the Windows client.

Adam

On 2/17/22 17:33, Adam Thorn via samba wrote:
> which would lead to two "-"s , whereas your snapshots just have
one.
I wondered about this too.
However I struggled to make it work until I saw an example which had the 
"-" on both options; I copied it, just in case, you know what, it
might
work... and to my surprise it did.


> Thus, a similar tcpdump might give you an idea as to whether your samba 
> set up is not responding with the right list of snapshots, or if the 
> fault lies with the Windows client.
Good idea!
I'll try as soon as I have the chance.

  bye & Thanks
	av.

On 2/17/22 17:33, Adam Thorn via samba wrote:
> I've tcpdumped on the samba server at the point I right click the 
> "Restore previous versions.." option on my Win10 client, and then
viewed
> the pcap in wireshark. I see my client sending a 
> FSCTL_SRV_ENUMERATE_SNAPSHOTS request, and then in the server reply I 
> look at the "Ioctl Response" part of the smb payload. That
response
> includes "Out data" looking like...
> 
> Number of snapshots: 19
> Snapshot: @GMT-2022.02.17-12.54.03
> Snapshot: @GMT-2022.02.17-06.54.03
> (etc etc)
> 
> The list of snapshots in the pcap matches what I expect based on running 
> zfs list -r -t snapshot -oname, and all of the snapshots display as 
> expected in the Windows previous version client.
Hello.

I finally had the chance to do this test.
The packet trace shows all the ZFS snapshots I expected, but Windows (10 
or 11) will only list the most recent.

At least now I know it's a client side problem.

  bye & Thanks
	av.