As discussed on the samba-technical mailing list:
When the new format parameter is used for the shadow_copy2 module, samba mistakenly classifies snapshots as wide links, and shadow copies do not work unless wide links are enabled.
I tracked down the underlying issue and proposed a fix, but am not familiar enough with samba internals to know if my fix is valid.
I've been running with my proposed fix for about 3 months now, seems to be working fine and I haven't noticed any ill effects. Any chance someone could look over my patch and see if it's suitable to apply, or if it needs any changes before this fix could be incorporated?
Please add the fix here as an attachment. That way we can track it in bugzilla, rather than it being off on the mailing list somewhere.
Created attachment 6418 [details]
Possible fix to not require wide links enabled when non-default shadow_copy2 format used
Ok, here's the patch, thanks...
Created attachment 6422 [details]
To be honest, rather than further modifying the shadow_copy2 module I would rather completely replace it. This module is so hard to understand with all its macros that I think it deserves a rewrite. Attached find my current work in progress that when finished is supposed to completely replace shadow_copy2. The sorting feature of shadow_copy2 is still missing, as might others. But to me, that module is a lot easier to understand than the current shadow_copy2 module.
For example, the attached module gets rid of the problems with wide links in a correct manner, not in the way the shadow_copy2 module was hacked up (with the CONNECTPATH VFS operation).
Just my 2ct.
What's the intended target for a new module? Would it be added to the 3.5 branch? Or 3.6? Or? While I'm all in favor of an improved implementation, any chance of adding one more bandaid to the existing module pending availability of something better :)? Particularly if the baidaid I've suggested is workable...
From a quick look at the shadow_copy3 module, it looks like you're hardcoding ".snapshots" into the snapshot path? In the version 2 module, the snapdir parameter indicated the actual directory the snapshots are in, not a directory containing a ".snapshots" directory.
Any update on this potential shadow copies replacement module? It would still be nice if somebody could consider applying this patch in the interim to the existing one, thanks...
The rewritten version didn't make it into 3.6, but it is available in master and it allows to specify the name of the snapshot directory.
Can you give that module a try to see if it works with non-standard snapdir names?
(In reply to comment #7)
> The rewritten version didn't make it into 3.6, but it is available in master
> and it allows to specify the name of the snapshot directory.
> Can you give that module a try to see if it works with non-standard snapdir
I tried the vfs_shadow_copy2.c module from master with 3.6.0 and it works fine with non-standard snapdir names.
I used the following config and test with a windows XP client.
vfs objects = shadow_copy2
shadow:sort = desc
shadow:snapdir = .snapshot
shadow:format = SNAP-%Y.%m.%d-%H.%M.%S
I have a modified patch of the above shadow_copy2 patch which is more
correct as it works properly for "narrow" symlinks (i.e. symlinks within
I also tried the shadow_copy3 too, but that worked even worse for me.
Specifically, it fails if the @GMT token is not at the beginning of the
path (according to the SMB specs, it can be anywhere).
Created attachment 6905 [details]
Fix access check
I know the long term goal is to migrate to the new shadow copy module, but while that's in the works it would be greatly appreciated if this patch could be applied while waiting. I'm currently using the Solaris bundled samba, and they're less than willing to apply patches that aren't applied to samba upstream.