Some years ago(*), all our TrueNAS “core” systems which had been installed prior to around 2020 / Version 12.0 (now all at 13.0-U6.1), have lost the ability to export available “previous versions” to the Windows Explorer (“There are no previous versions available”). Another TrueNAS core system, configured identically and installed last year at version 13.0-U5.3 is working fine.
The ‘.zfs/snapshot/’ folders at the datasets’ roots are accessible from the Windows clients and contain everything expected.
So far, I tried on an affected system:
1.) create a new independent dataset and share it → “previous versions” available: YES
2.) create a new folder within an existing dataset and share it → “previous versions” available: YES
3.) share an existing sub-folder within an existing dataset → “previous versions” available: YES
4.) de- and re-activate “shadow copies” for an existing share (smbd restarted in-between and the share remounted at the Windows client) → “previous versions” available: NO
5.) delete an existing share and re-create it → “previous versions” available: NO
As the systems are home to petabytes of data, moving things around is not an option; also linking the ‘.zfs/snapshot/’ folder to the share root is more of a transitional solution than a real workaround, as many of our users are not able to restore their files on their own - and most of the others get at least very confused by the “catastrophic failure” messages thrown by Windows, when they accidentally start working on a shadow copy.
Either you’re missing a crucial toggle, or this could indeed be permission- or ZFS property-related.
For curiosity, maybe compare these properties against each other between the datasets:
zfs list -o name,snapdir,snapdev,acltype,aclmode,aclinherit,xattr,utf8only,casesensitivity,sharesmb
Maybe something stands out, or perhaps a property was toggled in the past?
Since you created a brand new SMB Share from scratch, and it still will not let you expose “Previous Versions” on your Windows clients, it almost hints that there’s a lower-level issue?
How did you create the new share? Did you use the default preset?
The only differing zfs property to a new dataset is ‘xattr’, which now seems to default to ‘sa’ and is ‘on’ for the old shares. As the xattrs are available in both cases (albeit in different locations), I assume that this is not the root cause.
This issue appeared around end of 2020 on all our machines existing at that time (at least I was told so - this was long before I started working here) and there are several people on the internet, reporting similar issues around that time [1] . Which speaks against a toggled property, I’d say.
The new test shares with working version history were created without preset, configured (at the Web GUI) exactly like the old ones. (See attached screenshot.)
I agree, that this is most probably a zfs issue (permissions reportedly didn’t change and are the same as with the new test filesets), not a smb one. (‘ZFS’ tag added to the topic.)
EDIT: No SMB/share permissions are in use.
Do I understand correctly, that the ‘snapshots per dataset’ are relevant here? Otherwise on my shared test-datasets (in the same pool), the “previous versions” would not have been available, too…?
The total number of snapshots on the system I am working right now is 1361, quite evenly distributed over 10 datasets resp. shares. So no dataset is close to 200 snapshots.
And can you give me a hint on the logged error message to grep for? We do have messages in that file -_- but nothing looking relevant in plain sight.
You can grep for shadow_copy_zfs. If server is not busy you can bump up log level for SMB service to FULL or DEBUG and grep the log when trying to view them. Snapshots are only visible if written is non-zero (e.g. the snapshot differs from current data or other snapshots).
If you are using the fsrvp module then only snapshots created via that module will be visible. You should have it turned off unless you explicitly need it.
What a nice surprise: The migration from ‘core’ to ‘scale’ made the “previous versions” in Windoze Explorer accessible again, without any further action.
