[linux-cifs-client] Can't mount smb shares using mount.cifs with 2.6.31 kernel

[Jeff Layton]

On Fri, 16 Oct 2009 14:49:56 -0400
Jeff Layton <jlayton at redhat.com> wrote:

> On Fri, 16 Oct 2009 12:06:59 -0400
> Timothy Normand Miller <theosib at gmail.com> wrote:
> 
> > I'm sending you the captures privately.  The first one is just a
> > mount.  The second one is a mount with an ls.
> > 
> > On Fri, Oct 16, 2009 at 11:43 AM, Jeff Layton <jlayton at redhat.com> wrote:
> > > On Fri, 16 Oct 2009 11:35:07 -0400
> > > Timothy Normand Miller <theosib at gmail.com> wrote:
> > >
> > >> On Fri, Oct 16, 2009 at 10:50 AM, Jeff Layton <jlayton at redhat.com> wrote:
> > >> > On Fri, 16 Oct 2009 10:32:39 -0400
> > >> >
> > >> > A little. Can you try mounting again with "-o noserverino"? Perhaps
> > >> > something is wrong with the inode numbers being generated by the server
> > >> > here...
> > >>
> > >> That fixed the problem.  It mounts properly now.
> > >>
> > >> > If that doesn't help, then maybe also capture some debugging info of
> > >> > you doing an "ls" in the top-level dir after doing the mount.
> > >>
> > >> I can't tell where one set of debug messages end and where the next
> > >> set starts.  Is there something I can do to insert a dummy message
> > >> into dmesg so I can tell where to start copying?
> > >>
> > >> > I doubt this is anything you've done. There were a number of changes in
> > >> > how inodes are handled under CIFS between 2.6.30 and 2.6.31. It's quite
> > >> > possible that one of those changes is causing problems with this server.
> > >>
> > >> Thanks for the help.  Is there anything else I can do to diagnose the
> > >> cause so it can be fixed permanently?
> > >>
> > >>
> > >
> > > Yes, could you send me a wire capture of a mount on the 2.6.31 kernel
> > > without the "-o noserverino" option? I need to have a look at why the
> > > GetSrvInum call isn't doing the right thing here. There are
> > > instructions on the troubleshooting page for doing this.
> > >
> > > Thanks,
> > > --
> > > Jeff Layton <jlayton at redhat.com>
> > >
> > 
> > 
> > 
> 
> Thanks for the info. The mount seems to be successful. The ls makes
> CIFS issue a "FindFile First" which is how SMB does a READDIR on the
> wire. The server sends the response and then after that there is no
> further traffic. I assume that CIFS doesn't like that response for some
> reason, but wireshark unfortunately does not yet implement a dissector
> for the FFF infolevel in use here.
> 
> I'm going to see if I can fix that in wireshark and then may have a
> little more info. What may help in the meantime is the output from
> cifsFYI debugging turned up while doing an "ls" after a fresh mount
> without "-o noserverino".
> 

Yay. Figured out how to fix the wireshark dissector for this FindFile
infolevel. Wireshark patch attached that allows me to dissect these
packets correctly.  I'll plan to send that to the wireshark devs as
soon as I figure out where to send it. The good news is that I think I
see the problem. The bad news is that I'm not quite sure how to fix it
yet and it may even be a server bug.

Prior to 2.6.30, the default was to generate inode numbers out of the
air (noserverino). With 2.6.31, the default is "serverino" which makes
it so that we query the server for inode numbers. When mounting, we do
a QueryPathInfo against the root inode. With serverino enabled, we also
do a FileInternalInfo query against the file for the
"IndexNumber" (which I assumed was also the equivalent of the UniqueId
but maybe isn't?). In any case, that first call succeeds against this
server.

The problem comes in with the FindFile call. There we do a
FIND_FILE_ID_FULL_DIRECTORY_INFO infolevel query. That also succeeds,
but the inode number values in there (FileId's) are zeroed out. That's
technically within the letter of the spec for that call. When the
underlying filesystem doesn't support unique ID's, then it's supposed
to return 0. The problem is that it doesn't make much sense for the
server to claim that it does support unique ID's for one call but not
for others. 

Ideally, there'll be a way to deal with this automatically, but I'll
probably need to ponder this a bit. In any case, thanks for the problem
report. I'll let you know once I come up with something.

Cheers,
-- 
Jeff Layton <jlayton at redhat.com>