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

[Timothy Normand Miller]

On Fri, Oct 16, 2009 at 3:12 PM, Jeff Layton <jlayton at redhat.com> wrote:

>
> 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.
>

I'm very sorry I took so long to try out this patch.  It appears to
have done the trick.  Thanks!


-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project