FindFirst2 and DFS links
smfrench at gmail.com
Thu Mar 3 09:52:43 MST 2011
On Thu, Mar 3, 2011 at 8:02 AM, Suresh Jayaraman <sjayaraman at suse.de> wrote:
> Hi all,
> I'm looking into a CIFS client bug report where access to a DFS link
> fails with -EREMOTE error intermittently. Later accesses to the DFS link
> succeeds as dentry revalidation gets information about the DFS link.
> When the failure occurs, it appears that the Server (both Samba and
> Windows 2k8 server) returned -EREMOTE (NT_STATUS_PATH_NOT_COVERED) in
> response to the FindFirst2 call on the DFS link. Looking at the CIFS
> Spec, PATH_NOT_COVERED is not listed as one of the possible errors for
> FindFirst2. So it's not clear why the Server is sending the same.
> In order to handle this error, the CIFS client should find a way to
> figure out from the Server's FindFirst2 response that it is a DFS link.
> The only promising bit (in File attributes) is the "Reparse Point" which
> is set in the response from a Windows Server. However, the Reparse point
> could be something other than (symlinks or volume mountpoint etc) a DFS
> junction. Is there a way to clearly distinguish a DFS junction?
Yes - we have code to query a reparse point, but I doubt that is a good idea
> In short:
> * Is there a way to identify a DFS junction from the FindFirst2
> * Is NT_STATUS_PATH_NOT_COVERED error expected for a DFS junction in the
> FindFirst2 response?
I don't see it in the corresponding section of MS-CIFS (126.96.36.199.2.2) as a
return value but it seems plausible. The lookup (querypathinfo) on
the root directory already should have generated the path not covered so it
be a server bug. We may want to check if we create a cached inode for the
junction when we did a findfirst on the parent directory (ie there wasn't
a QueryPathInfo on the DFS junction before the Findfirst on the DFS
junction) - if so we could avoid caching the metadata information in
findfirst response for those entries which a reparse point.
In any case - we need a wireshark trace so we can open a dochep
request to Microsoft on the important missing rc in MS-CIFS.
> cFYI snip (for the curious)
> fs/cifs/readdir.c: CIFS VFS: in cifs_readdir as Xid: 105 with uid: 0
> fs/cifs/readdir.c: Full path: \\mydomain\dfsroot\dfslink start at: 2
> fs/cifs/cifssmb.c: In FindFirst for \\mydomain\dfsroot\dfslink
> fs/cifs/transport.c: For smb_command 50
> fs/cifs/transport.c: Sending smb of length 142
> fs/cifs/connect.c: rfc1002 length 0x27
> fs/cifs/connect.c: invalid transact2 word count
> Status code returned 0xc0000257 NT_STATUS_PATH_NOT_COVERED
> fs/cifs/netmisc.c: !!Mapping smb error code 3 to POSIX err -66 !!
> fs/cifs/cifssmb.c: Error in FindFirst = -66
> fs/cifs/readdir.c: initiate cifs search rc -66
> fs/cifs/readdir.c: CIFS VFS: leaving cifs_readdir (xid = 105) rc = -66
> fs/cifs/file.c: Closedir inode = 0xd3f3acf0
> fs/cifs/file.c: CIFS VFS: in cifs_closedir as Xid: 106 with uid: 0
> fs/cifs/file.c: Freeing private data in close dir
> fs/cifs/file.c: CIFS VFS: leaving cifs_closedir (xid = 106) rc = 0
> Suresh Jayaraman
More information about the samba-technical