*New 11.3 series Release:
2019-10-19: XigmaNAS 11.3.0.4.7014 - released

*New 12.0 series Release:
2019-10-05: XigmaNAS 12.0.0.4.6928 - released!

*New 11.2 series Release:
2019-09-23: XigmaNAS 11.2.0.4.6881 - released!

We really need "Your" help on XigmaNAS https://translations.launchpad.net/xigmanas translations. Please help today!

Producing and hosting XigmaNAS costs money. Please consider donating for our project so that we can continue to offer you the best.
We need your support! eg: PAYPAL

CIFS/SMB shadow copy issue - where to look?

CIFS/SMB network sharing.
Forum rules
Set-Up GuideFAQsForum Rules
Post Reply
birnbacs
Starter
Starter
Posts: 22
Joined: 04 Oct 2018 19:04
Status: Offline

CIFS/SMB shadow copy issue - where to look?

#1

Post by birnbacs » 30 Nov 2018 11:26

My system is suffering from not working shadow copies. I dug into this as far as I could go but seem to be unable to get it working.

Problem is, SMB does not seem to expose the created snapshot files. Right-clicking on a file on a Windows 7 client and selecting "previous file versions" takes a couple of seconds but never returns anything.

Details:
* auto snapshot tasks are running 4 times a day.
* I set a cron job to update a test file 4 times a day, every time after a snapshot was created
* enable shadow copy is ON
* shadow copy format is auto-%Y%m%d-%H0000, matching the snapshot name
* here are the gory details from the configuration file:

Code: Select all

		<autosnapshots>
			<autosnapshot>
				<uuid>0de65389-2792-4358-b4fe-a45d2b181d6a</uuid>
				<type>daily</type>
				<path>moonpool/files</path>
				<name>auto-%Y%m%d-%H0000</name>
				<snapshot>moonpool/files@auto-%Y%m%d-%H0000</snapshot>
				<recursive type="bool">1</recursive>
				<timeday>*</timeday>
				<timewday>*</timewday>
				<timehour>0400</timehour>
				<timemin>0000</timemin>
				<lifetime>0</lifetime>
			</autosnapshot>
			<autosnapshot>
				<uuid>0d6b4c1c-a122-45fb-a003-902fb20b27e9</uuid>
				<type>daily</type>
				<path>moonpool/files</path>
				<name>auto-%Y%m%d-%H0000</name>
				<snapshot>moonpool/files@auto-%Y%m%d-%H0000</snapshot>
				<recursive type="bool">1</recursive>
				<timeday>*</timeday>
				<timewday>*</timewday>
				<timehour>1000</timehour>
				<timemin>0000</timemin>
				<lifetime>2w</lifetime>
			</autosnapshot>
			<autosnapshot>
				<uuid>9653024e-87e9-462b-ae03-3f87416729b5</uuid>
				<type>daily</type>
				<path>moonpool/files</path>
				<name>auto-%Y%m%d-%H0000</name>
				<snapshot>moonpool/files@auto-%Y%m%d-%H0000</snapshot>
				<recursive type="bool">1</recursive>
				<timeday>*</timeday>
				<timewday>*</timewday>
				<timehour>1200</timehour>
				<timemin>0000</timemin>
				<lifetime>180d</lifetime>
			</autosnapshot>
			<autosnapshot>
				<uuid>8770a19f-ad4c-4ff7-9785-e30e8941da3b</uuid>
				<type>daily</type>
				<path>moonpool/files</path>
				<name>auto-%Y%m%d-%H0000</name>
				<snapshot>moonpool/files@auto-%Y%m%d-%H0000</snapshot>
				<recursive type="bool">1</recursive>
				<timeday>*</timeday>
				<timewday>*</timewday>
				<timehour>1400</timehour>
				<timemin>0000</timemin>
				<lifetime>2w</lifetime>
			</autosnapshot>
* snapshots do create the proper directories, e.g. /mnt/moonpool/files/.zfs/snapshot/auto-20181130-100000
* one thing, however, is that the shell shows me plenty of directories in yellow (hinting at ACLs) but lately created directories are in normal colors
Could this be an ACL issue? I did enable ACLs (by way of meddling) but did not check Inherit ACL; Alternate Data Streams, or NTFS ACLs:

* SMB/CIFS seems to be properly configured (from /var/etc/smb4.conf):

Code: Select all

[Files]
comment = kein Kommentar
path = /mnt/moonpool/files/
writeable = yes
printable = no
veto files = /.snap/.sujournal/
hide dot files = yes
guest ok = no
inherit permissions = yes
vfs objects = shadow_copy2 zfsacl recycle aio_pthread
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
recycle:repository = .recycle/%U
recycle:keeptree = yes
recycle:versions = yes
recycle:touch = yes
recycle:directory_mode = 0777
recycle:subdir_mode = 0700
shadow:format = auto-%Y%m%d-%H%M%S
shadow:snapdir = .zfs/snapshot
shadow:snapdirseverywhere = yes
shadow:sort = desc
shadow:localtime = yes
veto files = /.zfs/
The last line about 'veto files' seemed suspicious to me so I deleted it and restarted the server (/etc/rc.d/samba restart). No idea where the tnry came from but removing it did not help after all.

Ideas, anybody?

doktornotor
Advanced User
Advanced User
Posts: 182
Joined: 16 May 2017 00:22
Status: Offline

Re: CIFS/SMB shadow copy issue - where to look?

#2

Post by doktornotor » 30 Nov 2018 16:36

That has nothing with veto files. It is a Samba + ZFS ACL bug.

https://bugzilla.samba.org/show_bug.cgi?id=13175

Somehow, it's been working again for me in past couple of releases (at least with W10/2016/2019).

birnbacs
Starter
Starter
Posts: 22
Joined: 04 Oct 2018 19:04
Status: Offline

Re: CIFS/SMB shadow copy issue - where to look?

#3

Post by birnbacs » 30 Nov 2018 18:49

Thanks but I am not sure this is what bugs me.

I created another share "data" for playing and it provides working shadowcopies, only I can't see the .zfs folder. I also still have the original "files" share which does have a .zfs folder but does not provide working shadow copies.

Code: Select all

smbclient -U myuser%mypassword //localhost/files
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Nov  7 10:31:52 2018
  ..                                  D        0  Fri Nov 30 18:18:55 2018
  Alben                               D        0  Fri Nov 30 16:04:31 2018
  Statistics                          D        0  Mon Oct  8 09:28:45 2018
  .recycle                           DH        0  Thu Oct  4 10:37:29 2018
  ._.TemporaryItems                   H     4096  Tue Aug  5 13:07:31 2014
  Software                            D        0  Fri Nov 23 18:59:35 2018
  Mandanten                           D        0  Fri Jan 19 15:29:28 2018
  .TemporaryItems                    DH        0  Tue Aug  5 13:07:32 2014
  ._.DS_Store                         H     4096  Wed Feb 18 10:53:45 2015
  KnowHow                             D        0  Fri Jul 13 14:20:58 2018
  .DS_Store                          AH     6148  Fri Dec 11 08:22:17 2015
  Musik                               D        0  Tue Jan 23 17:52:02 2018
  Admin                               D        0  Mon Oct  8 09:31:59 2018

                1563150010 blocks of size 1024. 1141795884 blocks available
smb: \>
You will note that the .zfs directory is missing.
This makes sense because /var/etc/smb4.conf has the .zfs directory as "veto file" (see my original post). According to
https://www.samba.org/samba/docs/curren ... #VETOFILES such files are not visible and not accessible.
When I delete the entry from /var/etc/smb4.conf and start smb, the line gets re-inserted.

Here is how the data share looks on smbclient:

Code: Select all

smbclient -U myuser%mypassword //localhost/data
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Fri Nov 30 18:22:14 2018
  ..                                  D        0  Fri Nov 30 18:18:55 2018
  .recycle                           DH        0  Fri Nov 30 18:22:14 2018
  nothing.txt                         A      159  Fri Nov 30 18:19:24 2018

                1246653277 blocks of size 1024. 1246653242 blocks available
smb: \>
No .zfs directory but there is none under /mnt/moonpool/data either.
Trying to find one the hard way (find /mnt/moonpool -type d -name ".zfs") resulted in one hit (/mnt/moonpool/files/.zfs) and an endless search.

More mystery: the snapshots for the "data" share are reported as "moonpool/data@auto-20181129-173000".
As I said there is no .zfs directory under mnt/moonpool/data and the GUI should not even permit to run an auto-Snapshot at half hour.

doktornotor
Advanced User
Advanced User
Posts: 182
Joined: 16 May 2017 00:22
Status: Offline

Re: CIFS/SMB shadow copy issue - where to look?

#4

Post by doktornotor » 01 Dec 2018 11:44

birnbacs wrote:
30 Nov 2018 18:49
I created another share "data" for playing and it provides working shadowcopies, only I can't see the .zfs folder. I also still have the original "files" share which does have a .zfs folder but does not provide working shadow copies.
As noted
- there is a well known Samba bug regarding Previous versions
- you do not need to see the virtual .zfs directory; when you

Code: Select all

cd .zfs
you still can see the snapshots under snapshots/ directory below .zfs

User avatar
ms49434
Developer
Developer
Posts: 718
Joined: 03 Sep 2015 18:49
Location: Neuenkirchen-Vörden, Germany - GMT+1
Contact:
Status: Offline

Re: CIFS/SMB shadow copy issue - where to look?

#5

Post by ms49434 » 01 Dec 2018 12:46

You can enable/disable snapshot visibility (the .zfs folder) in the dataset properties.
1) XigmaNAS 12.0.0.4 amd64-embedded on a Dell T20 running in a VM on ESXi 6.7U2, 22GB out of 32GB ECC RAM, LSI 9300-8i IT mode in passthrough mode. Pool 1: 2x HGST 10TB, mirrored, SLOG: Samsung 850 Pro, L2ARC: Samsung 850 Pro, Pool 2: 1x Samsung 860 EVO 1TB , services: Samba AD, CIFS/SMB, ftp, ctld, rsync, syncthing, zfs snapshots.
2) XigmaNAS 12.0.0.4 amd64-embedded on a Dell T20 running in a VM on ESXi 6.7U2, 8GB out of 32GB ECC RAM, IBM M1215 crossflashed, IT mode, passthrough mode, 2x HGST 10TB , services: rsync.

birnbacs
Starter
Starter
Posts: 22
Joined: 04 Oct 2018 19:04
Status: Offline

Re: CIFS/SMB shadow copy issue - where to look?

#6

Post by birnbacs » 07 Dec 2018 10:42

One more step on the path to enlightenment:
* .zfs/ is a virtual directory. It exists even though it may be invisible. Snapshots of different datasets may end up side by side
* doktornotor was right: it IS the known bug. Could have found out earlier by trying (and failing) to actually list the .zfs directory

Unfortunately the server meanwhile developed other ACL-related problems. Users of the same group have stopped being able to write-access one another's files. I will update to the -P3 version today and report.

Post Reply

Return to “CIFS/SMB (Samba)”