I' m using 4.1.0rc4-3086-SUSE-oS13.2-x86_64 and I' m not able to get shadow_copy2 working with a btrfs read only snapshot. # ls -al /nas/.snapshot total 8 drwxr-xr-x 1 root root 48 Nov 7 23:28 . drwxrwxrwx 1 root root 170 Nov 6 23:22 .. drwxrwxrwx 1 root root 170 Nov 6 23:22 @GMT-2013.11.06-22.22.05 First try smb.conf [nas] inherit acls = Yes path = /nas read only = No guest ok = Yes vfs objects = shadow_copy2 shadow:snapdir = /nas/.snapshot shadow:basedir = /nas shadow:sort = desc Error message when opening previous version [2013/11/09 16:21:14.339509, 0] ../source3/modules/vfs_shadow_copy2.c:1113(shadow_copy2_get_shadow_copy_data) shadow:snapdir not found for /nas in get_shadow_copy_data [2013/11/09 16:21:14.339642, 0] ../source3/modules/vfs_default.c:1133(vfswrap_fsctl) FSCTL_GET_SHADOW_COPY_DATA: connectpath /nas, failed. Second try: shadow:snapdir = .snapshot shadow:basedir = /nas No error message, but Windows previous version does not show anything Third try: shadow:snapdir = ../.snapshot shadow:basedir = /nas No error message and I can access the previous version and I can open the folder. But I cannot access any of the old files, I just see the contents of the root folder and not the folder I'm accessing. If I try a folder one level below the share root folder I don't see any previous versions.
Thanks for the bug report. A patchset has recently been added to master that fixes various issues with the shadow_copy2 module. I'll shortly provide a backport patchset for 4.1 and 4.0. Michael
Created attachment 9517 [details] patch for 4.1, cherry-picked from master This is the set of patches as cherry-picked from master.
Created attachment 9518 [details] patch for 4.0, cherry-picked from master Patchset, as cherry-picked from master.
Comment on attachment 9518 [details] patch for 4.0, cherry-picked from master I'd like to get this into 4.0, too
Which piece of this patchset actually fixes the bug that was reported?
Let's hold this off for now: - Volker has spotted one thing in the code that should be clarified. - We should generally discuss/decide how minimal vs. complete patchsets for the releases should be that get picked from master. Thanks - Michael
In case it helps to understand the usefulness of this patch, I am running samba 4.0.9 on debian wheezy, and shadow copy was not working for me at all until I applied the patch for 4.0 and recompiled samba. Highlights from my smb.conf :- [global] log level = 1 vfs:2 unix extensions = no [Pluto] path = /srv/share/Pluto vfs objects = shadow_copy2 shadow:snapdir = ../../srv/shadow-copy/srv/share/ shadow:basedir = /srv/share wide links = yes The mount point for /srv/share/Pluto is /srv/share. The snapshot directories are in /srv/shadow-copy/srv/share/. It's quite possible that my smb.conf is wrong or sub-optimal; I had trouble finding up-to-date documentation on shadow_copy2 - there is man vfs_shadow_copy2 but it claims to be for version 3.2.7.
Created attachment 9559 [details] Updated patchset for v4-1-test Updated patchset with three additional patches from master picked: - c16afddeef2938e218df63b1c669caa5fb65d39c (manpage typo fixes for the changes in the patchset) - 71318d7d685f8e1e112076f84ef2d788acb83547 (reverts expensive unneccessary zero-init introduced by patchset) - 0be19bce56bede1efac59054aa98b680c9f1a351 (adds comment explaining why we may skip the 0-initialization) This is the complete patchset now.
Created attachment 9560 [details] Updated patchset for v4-0-test Updated patchset for v4-0-test with the same additional patches picked as for the v4-1 patchset.
Comment on attachment 9518 [details] patch for 4.0, cherry-picked from master obsoleted by updated patchset
I agree that the bug report is a bit unspecific. David Kegel has reported one setting that fixed by this. There were various regressions to 3.6 code for setups that basically relate to absolute-snapdir mode and the non-snapdirseverywhere mode. The patchset (in non-polished form) has also been reported to fix such scenarios on the mailing list. The issue that Volker had spotted when reviewing the patches has been fixed by the additional patches in the updated patchsets. Regarding the question how minimal the patchset should be, I'd still favour taking the whole patchset which fixes various issues and also does some irrelevant comment changes, instead of redoing the master code changes for bugzilla, which would be a major effort (at least for me). This is really isolated code, and it will make it easier to simply pick future bugfix patches from master. Christof, as you indicated to me your interest, I'll give you the opportunity to review these patchset for inclusion into 4.1 and optionally also 4.0. If you agree, please add your review and pass the bug to Karolin for inclusion. Thanks - Michael
Created attachment 9561 [details] Updated patchset for v4-1-test Gosh, last patchset was broken; because i did "git log .... > file" instead of "git format-patch --stdout ... > file" .... This is what I intended to attach...
==> Karolin for inclusion into 4.1.NEXT and 4.0.NEXT
Pushed to autobuild-v4-1-test and v4-0-test.
Pushed to v4-1-test and v4-0-test. Closing out bug report. Thanks!