Re: mounting cifs filesystems not possible

[Gerhard Hintermayer <gerhard.hintermayer@gmail.com>]

Sorry, wireshark not installed.
The strange thing is, that sometimes mounting succeeds. So it
should'nt be an issue with the root share (unless the server doesn't
always answer in the same way)
Here's a dmesg output with a successful mount. (had to try for several
times, unloading/loading of module cifs is not necessary)
The only diffs which might be the cause are different flags (64 vs 0
when unable to mount) in line 1 and a different Xid in line 2.

 fs/cifs/cifsfs.c: Devname: //BRKVN05/AtlasPM flags: 64
 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 97 with uid: 0
 fs/cifs/connect.c: Username: aprol
 fs/cifs/connect.c: UNC: \\BRKVN05\AtlasPM ip: 10.5.12.105
 fs/cifs/connect.c: Socket created
 fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x2bc
 fs/cifs/connect.c: Existing smb sess not found
 fs/cifs/cifssmb.c: secFlags 0x7
 fs/cifs/transport.c: For smb_command 114
 fs/cifs/transport.c: Sending smb:  total_len 51
 fs/cifs/connect.c: Demultiplex PID: 31969
 fs/cifs/connect.c: rfc1002 length 0x6f
 fs/cifs/cifssmb.c: Dialect: 0
 fs/cifs/cifssmb.c: negprot rc 0
 fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x1f3fd TimeAdjust: -7200
 fs/cifs/sess.c: sess setup type 2
 fs/cifs/transport.c: For smb_command 115
 fs/cifs/transport.c: Sending smb:  total_len 242
 fs/cifs/connect.c: rfc1002 length 0xc7
 fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
 fs/cifs/sess.c: ssetup rc from sendrecv2 is 0
 fs/cifs/sess.c: UID = 20482
 fs/cifs/sess.c: bleft 153
 fs/cifs/sess.c: words left: 0
 fs/cifs/sess.c: ssetup freeing small buf f031ae40
 fs/cifs/connect.c: CIFS Session Established successfully
 fs/cifs/connect.c: file mode: 0x5f7  dir mode: 0x1ff
 fs/cifs/transport.c: For smb_command 117
 fs/cifs/transport.c: Sending smb:  total_len 90
 fs/cifs/connect.c: rfc1002 length 0x42
 fs/cifs/connect.c: disk share connection
 fs/cifs/connect.c: Tcon flags: 0x1
 fs/cifs/connect.c: CIFS Tcon rc = 0
 fs/cifs/cifssmb.c: In QFSDeviceInfo
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 72
 fs/cifs/connect.c: rfc1002 length 0x44
 fs/cifs/cifssmb.c: In QFSAttributeInfo
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 72
 fs/cifs/connect.c: rfc1002 length 0x50
 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 97) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_iget as Xid: 98 with uid: 0
 fs/cifs/inode.c: Getting info on
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 78
 fs/cifs/connect.c: rfc1002 length 0xb8
 fs/cifs/inode.c: Old time 0
 fs/cifs/inode.c: New time 67264957

Gerhard

On Thu, Jul 23, 2009 at 9:44 AM, Steve French<smfrench@gmail.com> wrote:
> On Thu, Jul 23, 2009 at 1:24 AM, Gerhard
> Hintermayer<gerhard.hintermayer@gmail.com> wrote:
>> See my original post to LKML at http://lkml.org/lkml/2009/7/15/217.
>> You can see kernel version, and dmesg output (including cifsFYI set to
>> 7) there.
>> I did file a bug report to gentoo bug list and lkml. Shall I also do
>> so for bugzilla.samba.org ? I think it's more kernel related.
>>
>> The DebugData of the share I'm trying to mount (fortunaltely I got a
>
>> mount -t cifs -o user=aprol,password=*****,ip=10.5.12.105 //BRKVN05/AtlasPM /mnt/AtlasPM
>
> The mount syntax you listed in your post is a little strange with the
> mount options preceding rather than following the UNC name and device,
> ie rather than the usual:
>              mount.cifs {//unc-name} {mount-point} [-o options]
>
> It looks like the first 3/4 of mount succeeded (setting up a session,
> and connecting to the share) to the point of doing the lookup of the
> root directory of the share (which I don't see in your trace).
> Typically there have been the following reasons for that to fail:
> 1) the user has no permission on the root of the share
> or
> 2) the root of the share is a dfs referral to another server (this
> should work now, but was probably not supported a few kernel releases
> ago)
> or
> 3) the server reports that the root directory is not a directory (ie
> is a file for example)
>
> It may be that an earlier mount failed perhaps oopsing in the vfs, and
> that could have left an existing cifs session and tree connection
> which made it seem like a later mount worked (since it found an
> existing session) but that seems unlikely.
>
> It would be helpful to see if the client did a network request (in
> this case SMB transact2 Query Path Info) on the root directory of the
> share, so if you have a wireshark trace that would be useful.
> --
> Thanks,
>
> Steve
>