[PATCH] smbd: Fix snapshot query on shares with DFS enabled

[Jeremy Allison]

On Mon, Aug 15, 2016 at 04:25:10PM -0700, Christof Schmitt wrote:
> On Fri, Aug 12, 2016 at 04:51:35PM -0700, Jeremy Allison wrote:
> > On Fri, Aug 12, 2016 at 03:59:27PM -0700, Christof Schmitt wrote:
> > > From 3a33435fc3d61605c75ed3f3b87612fbe729b553 Mon Sep 17 00:00:00 2001
> > > From: Christof Schmitt <cs at samba.org>
> > > Date: Fri, 12 Aug 2016 14:59:07 -0700
> > > Subject: [PATCH] smbd: Fix snapshot query on shares with DFS enabled
> > > 
> > > When DFS is enabled (host msdfs = yes and msdfs root = yes), then SMB
> > > clients send create requests in the format \hostname\service\path.
> > > Putting the GMT tag as first element breaks the DFS parsing and results
> > > in OBJECT_NOT_FOUND for snapshotted files.  Fix this by appending the
> > > GMT tag to the end of the path.
> > 
> > Great catch ! Pushed with additional comment:
> > 
> > BUG: https://bugzilla.samba.org/show_bug.cgi?id=12150
> > 
> > as we're going to need this backported.
> 
> I just came across one more thing: The test is on a system with the
> shadowcopy2 module enabled. While the patches fixes the problem for
> directories, there seems to be an issue when a SMB client is explicitly
> asking for older versions of a file. It looks like shadowcopy leaves a
> trailing slash from the GMT tag removal:
> 
> (test is a file, not  a directory)
> 
> [2016/08/15 16:12:36.178799, 10, pid=13125, effective(12000500, 12000513), real(12000500, 0)] ../source3/modules/vfs_shadow_copy2.c:245(shadow_copy2_strip_snapshot)
>   ../source3/modules/vfs_shadow_copy2.c:245: enter path 'test/@GMT-2016.08.12-19.56.11'
> [2016/08/15 16:12:36.178814, 10, pid=13125, effective(12000500, 12000513), real(12000500, 0)] ../source3/modules/vfs_shadow_copy2.c:462(shadow_copy2_do_convert)
>  converting 'test/'
> [2016/08/15 16:12:36.178837, 10, pid=13125, effective(12000500, 12000513), real(12000500, 0)] ../source3/modules/vfs_shadow_copy2.c:604(shadow_copy2_do_convert)
>  Trying[snapdirseverywhere] /fs1/smbexport1/test/.snapshots/@GMT-2016.08.12-19.56.11/: -1 (Not a directory)
> [2016/08/15 16:12:36.178860, 10, pid=13125, effective(12000500, 12000513), real(12000500, 0)] ../source3/modules/vfs_shadow_copy2.c:604(shadow_copy2_do_convert)
>  Trying[snapdirseverywhere] /fs1/smbexport1/.snapshots/@GMT-2016.08.12-19.56.11/test/: -1 (No such file or directory)
> [2016/08/15 16:12:36.178886, 10, pid=13125, effective(12000500, 12000513), real(12000500, 0)] ../source3/modules/vfs_shadow_copy2.c:604(shadow_copy2_do_convert)
>  Trying[snapdirseverywhere] /fs1/.snapshots/@GMT-2016.08.12-19.56.11/smbexport1/test/: -1 (Not a directory)
> 
> I will try to take a closer look tomorrow, maybe that can be easily
> handled in the shadowcopy2 module. The backport should probably wait
> until this is resolved

We should probably add a smbclient-based torture test
for both file and directory inside source3/script/tests/test_shadow_copy.sh
once this gets fixed to make sure we don't regress.