Can't mount smb shares using mount.cifs with 2.6.31 kernel
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Timothy Normand Miller
::
Rate this Message:
Hi, everyone. I'm experiencing a peculiar problem mounting smb
shares, and I hope someone can help. I've tried googling for this, but what I come up with seems to be related to much older kernels. Since updating to 2.6.31 from 2.6.30, I am no longer able to mount SMB shares using mount.cifs. When I try to mount, it behaves as though the mount succeeded (no error messages anywhere), but the mount point is empty. If I boot up in 2.6.30, smb mounts work again, so this is specific to 2.6.31. Also, I have verified (to the best of my ability) that my cifs and samba-related kernel configuration parameters are identical. Any idea what might be going on here? Thanks. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Jeff Layton-2
::
Rate this Message:
On Fri, 16 Oct 2009 01:24:15 -0400
Timothy Normand Miller <theosib@...> wrote: > Hi, everyone. I'm experiencing a peculiar problem mounting smb > shares, and I hope someone can help. I've tried googling for this, > but what I come up with seems to be related to much older kernels. > > Since updating to 2.6.31 from 2.6.30, I am no longer able to mount SMB > shares using mount.cifs. When I try to mount, it behaves as though > the mount succeeded (no error messages anywhere), but the mount point > is empty. If I boot up in 2.6.30, smb mounts work again, so this is > specific to 2.6.31. Also, I have verified (to the best of my ability) > that my cifs and samba-related kernel configuration parameters are > identical. > > Any idea what might be going on here? > > Thanks. > Not a lot of info to go on here. Maybe read over the LinuxCIFS troubleshooting page (that I just wrote), and gather some of the basic info we'll need to help you. http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting Thanks, -- Jeff Layton <jlayton@...> _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Timothy Normand Miller
::
Rate this Message:
On Fri, Oct 16, 2009 at 8:59 AM, Jeff Layton <jlayton@...> wrote:
> On Fri, 16 Oct 2009 01:24:15 -0400 > Timothy Normand Miller <theosib@...> wrote: > >> Hi, everyone. I'm experiencing a peculiar problem mounting smb >> shares, and I hope someone can help. I've tried googling for this, >> but what I come up with seems to be related to much older kernels. >> >> Since updating to 2.6.31 from 2.6.30, I am no longer able to mount SMB >> shares using mount.cifs. When I try to mount, it behaves as though >> the mount succeeded (no error messages anywhere), but the mount point >> is empty. If I boot up in 2.6.30, smb mounts work again, so this is >> specific to 2.6.31. Also, I have verified (to the best of my ability) >> that my cifs and samba-related kernel configuration parameters are >> identical. >> >> Any idea what might be going on here? >> >> Thanks. >> > > Not a lot of info to go on here. Maybe read over the LinuxCIFS > troubleshooting page (that I just wrote), and gather some of the basic > info we'll need to help you. > > http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting > 2.6.30-gentoo-r6 mount.cifs version: 1.12 The server is an Apple Airport Extreme Base Station with two attached external drives. I have no trouble mounting them from Linux 2.6.30 or from Windows machines or Macs. Here's what I get in dmesg when I unmount and remount the fs under 2.6.30 when debugging is enabled: fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 16 with uid: 0 fs/cifs/inode.c: Revalidate: inode 0xffff88022c6c7d68 count 1 dentry: 0xffff88022c49f3c0 d_time -2129793504 jiffies 4298241016 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 0x88 fs/cifs/inode.c: Old time 4295679883 fs/cifs/inode.c: New time 4298241016 fs/cifs/inode.c: cifs_revalidate - inode unchanged fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 16) rc = 0 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 17 with uid: 0 fs/cifs/inode.c: Revalidate: inode 0xffff88022c6c7d68 count 1 dentry: 0xffff88022c49f3c0 d_time -2129793504 jiffies 4298241048 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 17) rc = 0 fs/cifs/cifsfs.c: CIFS VFS: in cifs_statfs as Xid: 18 with uid: 0 fs/cifs/cifssmb.c: In QFSInfo fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb: total_len 72 fs/cifs/connect.c: rfc1002 length 0x54 fs/cifs/cifssmb.c: Blocks: 122012668 Free: 31902065 Block size 4096 fs/cifs/cifsfs.c: CIFS VFS: leaving cifs_statfs (xid = 18) rc = 0 fs/cifs/cifsfs.c: In cifs_put_super fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 19 with uid: 0 fs/cifs/cifssmb.c: In tree disconnect fs/cifs/transport.c: For smb_command 113 fs/cifs/transport.c: Sending smb: total_len 39 fs/cifs/connect.c: rfc1002 length 0x27 fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 20 with uid: 0 fs/cifs/cifssmb.c: In SMBLogoff for session disconnect fs/cifs/transport.c: For smb_command 116 fs/cifs/transport.c: Sending smb: total_len 43 fs/cifs/connect.c: rfc1002 length 0x2b fs/cifs/cifsfs.c: Devname: //timapx/NetworkShared flags: 64 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 21 with uid: 0 fs/cifs/connect.c: iocharset set to utf8 fs/cifs/connect.c: Username: root fs/cifs/connect.c: UNC: \\timapx\NetworkShared ip: 192.168.1.64 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/connect.c: Demultiplex PID: 21955 fs/cifs/cifssmb.c: secFlags 0x7 fs/cifs/transport.c: For smb_command 114 fs/cifs/transport.c: Sending smb: total_len 60 fs/cifs/connect.c: rfc1002 length 0x51 fs/cifs/cifssmb.c: Dialect: 0 fs/cifs/cifssmb.c: negprot rc 0 fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x207c TimeAdjust: 14400 fs/cifs/transport.c: For smb_command 115 fs/cifs/transport.c: Sending smb: total_len 240 fs/cifs/connect.c: rfc1002 length 0x7c 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 = 0 fs/cifs/sess.c: bleft 78 fs/cifs/sess.c: serverOS=Apple Base Station fs/cifs/sess.c: serverNOS=CIFS 4.32 fs/cifs/sess.c: serverDomain=WORKGROUP fs/cifs/sess.c: ssetup freeing small buf ffff88022aa3cb80 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 100 fs/cifs/connect.c: rfc1002 length 0x3c fs/cifs/connect.c: disk share connection fs/cifs/connect.c: nativeFileSystem=FAT32 fs/cifs/connect.c: Tcon flags: 0x0 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 0x52 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 21) rc = 0 fs/cifs/inode.c: CIFS VFS: in cifs_iget as Xid: 22 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 0x88 fs/cifs/inode.c: Old time 0 fs/cifs/inode.c: New time 4298241509 When 2.6.31 boots, ostensibly, it acts as though it was mounted, but I do see this in dmesg: CIFS VFS: Error connecting to socket. Aborting operation CIFS VFS: cifs_mount failed w/return code = -111 CIFS VFS: Error connecting to socket. Aborting operation CIFS VFS: cifs_mount failed w/return code = -111 CIFS VFS: Error connecting to socket. Aborting operation CIFS VFS: cifs_mount failed w/return code = -111 Here are the debug messages I get when umounting and remounting: fs/cifs/cifsfs.c: Devname: //timapx/NetworkShared flags: 64 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 3 with uid: 0 fs/cifs/connect.c: iocharset set to utf8 fs/cifs/connect.c: Username: root fs/cifs/connect.c: UNC: \\timapx\NetworkShared ip: 192.168.1.64 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/connect.c: Demultiplex PID: 19187 fs/cifs/cifssmb.c: secFlags 0x7 fs/cifs/transport.c: For smb_command 114 fs/cifs/transport.c: Sending smb: total_len 60 fs/cifs/connect.c: rfc1002 length 0x51 fs/cifs/cifssmb.c: Dialect: 0 fs/cifs/cifssmb.c: negprot rc 0 fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x207c TimeAdjust: 14400 fs/cifs/sess.c: sess setup type 2 fs/cifs/transport.c: For smb_command 115 fs/cifs/transport.c: Sending smb: total_len 240 fs/cifs/connect.c: rfc1002 length 0x7c fs/cifs/sess.c: ssetup rc from sendrecv2 is 0 fs/cifs/sess.c: UID = 0 fs/cifs/sess.c: bleft 78 fs/cifs/sess.c: serverOS=Apple Base Station fs/cifs/sess.c: serverNOS=CIFS 4.32 fs/cifs/sess.c: serverDomain=WORKGROUP fs/cifs/sess.c: ssetup freeing small buf ffff88022a07fdc0 fs/cifs/connect.c: CIFS Session Established successfully fs/cifs/connect.c: file mode: 0x1ed dir mode: 0x1ed fs/cifs/transport.c: For smb_command 117 fs/cifs/transport.c: Sending smb: total_len 100 fs/cifs/connect.c: rfc1002 length 0x3c fs/cifs/connect.c: disk share connection fs/cifs/connect.c: nativeFileSystem=FAT32 fs/cifs/connect.c: Tcon flags: 0x0 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 0x52 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 3) rc = 0 fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid: 4 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 0x88 fs/cifs/cifssmb.c: In GetSrvInodeNum for fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb: total_len 78 fs/cifs/connect.c: rfc1002 length 0x48 fs/cifs/inode.c: looking for uniqueid=128957191926360064 fs/cifs/inode.c: inode 0xffff880225c48d90 old_time=0 new_time=4294953719 Does this tell you anything useful? I could have some other kernel parameter wrong, but I couldn't begin to imagine what it might be. Thanks. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Jeff Layton-2
::
Rate this Message:
On Fri, 16 Oct 2009 10:32:39 -0400
Timothy Normand Miller <theosib@...> wrote: > On Fri, Oct 16, 2009 at 8:59 AM, Jeff Layton <jlayton@...> wrote: > > On Fri, 16 Oct 2009 01:24:15 -0400 > > Timothy Normand Miller <theosib@...> wrote: > > > >> Hi, everyone. I'm experiencing a peculiar problem mounting smb > >> shares, and I hope someone can help. I've tried googling for this, > >> but what I come up with seems to be related to much older kernels. > >> > >> Since updating to 2.6.31 from 2.6.30, I am no longer able to mount SMB > >> shares using mount.cifs. When I try to mount, it behaves as though > >> the mount succeeded (no error messages anywhere), but the mount point > >> is empty. If I boot up in 2.6.30, smb mounts work again, so this is > >> specific to 2.6.31. Also, I have verified (to the best of my ability) > >> that my cifs and samba-related kernel configuration parameters are > >> identical. > >> > >> Any idea what might be going on here? > >> > >> Thanks. > >> > > > > Not a lot of info to go on here. Maybe read over the LinuxCIFS > > troubleshooting page (that I just wrote), and gather some of the basic > > info we'll need to help you. > > > > http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting > > > > 2.6.30-gentoo-r6 > mount.cifs version: 1.12 > > The server is an Apple Airport Extreme Base Station with two attached > external drives. I have no trouble mounting them from Linux 2.6.30 or > from Windows machines or Macs. > > Here's what I get in dmesg when I unmount and remount the fs under > 2.6.30 when debugging is enabled: > > fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 16 with uid: 0 > fs/cifs/inode.c: Revalidate: inode 0xffff88022c6c7d68 count 1 > dentry: 0xffff88022c49f3c0 d_time -2129793504 jiffies 4298241016 > 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 0x88 > fs/cifs/inode.c: Old time 4295679883 > fs/cifs/inode.c: New time 4298241016 > fs/cifs/inode.c: cifs_revalidate - inode unchanged > fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 16) rc = 0 > fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 17 with uid: 0 > fs/cifs/inode.c: Revalidate: inode 0xffff88022c6c7d68 count 1 > dentry: 0xffff88022c49f3c0 d_time -2129793504 jiffies 4298241048 > fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 17) rc = 0 > fs/cifs/cifsfs.c: CIFS VFS: in cifs_statfs as Xid: 18 with uid: 0 > fs/cifs/cifssmb.c: In QFSInfo > fs/cifs/transport.c: For smb_command 50 > fs/cifs/transport.c: Sending smb: total_len 72 > fs/cifs/connect.c: rfc1002 length 0x54 > fs/cifs/cifssmb.c: Blocks: 122012668 Free: 31902065 Block size 4096 > fs/cifs/cifsfs.c: CIFS VFS: leaving cifs_statfs (xid = 18) rc = 0 > fs/cifs/cifsfs.c: In cifs_put_super > fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 19 with uid: 0 > fs/cifs/cifssmb.c: In tree disconnect > fs/cifs/transport.c: For smb_command 113 > fs/cifs/transport.c: Sending smb: total_len 39 > fs/cifs/connect.c: rfc1002 length 0x27 > fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 20 with uid: 0 > fs/cifs/cifssmb.c: In SMBLogoff for session disconnect > fs/cifs/transport.c: For smb_command 116 > fs/cifs/transport.c: Sending smb: total_len 43 > fs/cifs/connect.c: rfc1002 length 0x2b > fs/cifs/cifsfs.c: Devname: //timapx/NetworkShared flags: 64 > fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 21 with uid: 0 > fs/cifs/connect.c: iocharset set to utf8 > fs/cifs/connect.c: Username: root > fs/cifs/connect.c: UNC: \\timapx\NetworkShared ip: 192.168.1.64 > 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/connect.c: Demultiplex PID: 21955 > fs/cifs/cifssmb.c: secFlags 0x7 > fs/cifs/transport.c: For smb_command 114 > fs/cifs/transport.c: Sending smb: total_len 60 > fs/cifs/connect.c: rfc1002 length 0x51 > fs/cifs/cifssmb.c: Dialect: 0 > fs/cifs/cifssmb.c: negprot rc 0 > fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x207c TimeAdjust: 14400 > fs/cifs/transport.c: For smb_command 115 > fs/cifs/transport.c: Sending smb: total_len 240 > fs/cifs/connect.c: rfc1002 length 0x7c > 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 = 0 > fs/cifs/sess.c: bleft 78 > fs/cifs/sess.c: serverOS=Apple Base Station > fs/cifs/sess.c: serverNOS=CIFS 4.32 > fs/cifs/sess.c: serverDomain=WORKGROUP > fs/cifs/sess.c: ssetup freeing small buf ffff88022aa3cb80 > 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 100 > fs/cifs/connect.c: rfc1002 length 0x3c > fs/cifs/connect.c: disk share connection > fs/cifs/connect.c: nativeFileSystem=FAT32 > fs/cifs/connect.c: Tcon flags: 0x0 > 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 0x52 > fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 21) rc = 0 > fs/cifs/inode.c: CIFS VFS: in cifs_iget as Xid: 22 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 0x88 > fs/cifs/inode.c: Old time 0 > fs/cifs/inode.c: New time 4298241509 > > When 2.6.31 boots, ostensibly, it acts as though it was mounted, but I > do see this in dmesg: > > CIFS VFS: Error connecting to socket. Aborting operation > CIFS VFS: cifs_mount failed w/return code = -111 > CIFS VFS: Error connecting to socket. Aborting operation > CIFS VFS: cifs_mount failed w/return code = -111 > CIFS VFS: Error connecting to socket. Aborting operation > CIFS VFS: cifs_mount failed w/return code = -111 > > Here are the debug messages I get when umounting and remounting: > > fs/cifs/cifsfs.c: Devname: //timapx/NetworkShared flags: 64 > fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 3 with uid: 0 > fs/cifs/connect.c: iocharset set to utf8 > fs/cifs/connect.c: Username: root > fs/cifs/connect.c: UNC: \\timapx\NetworkShared ip: 192.168.1.64 > 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/connect.c: Demultiplex PID: 19187 > fs/cifs/cifssmb.c: secFlags 0x7 > fs/cifs/transport.c: For smb_command 114 > fs/cifs/transport.c: Sending smb: total_len 60 > fs/cifs/connect.c: rfc1002 length 0x51 > fs/cifs/cifssmb.c: Dialect: 0 > fs/cifs/cifssmb.c: negprot rc 0 > fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x207c TimeAdjust: 14400 > fs/cifs/sess.c: sess setup type 2 > fs/cifs/transport.c: For smb_command 115 > fs/cifs/transport.c: Sending smb: total_len 240 > fs/cifs/connect.c: rfc1002 length 0x7c > fs/cifs/sess.c: ssetup rc from sendrecv2 is 0 > fs/cifs/sess.c: UID = 0 > fs/cifs/sess.c: bleft 78 > fs/cifs/sess.c: serverOS=Apple Base Station > fs/cifs/sess.c: serverNOS=CIFS 4.32 > fs/cifs/sess.c: serverDomain=WORKGROUP > fs/cifs/sess.c: ssetup freeing small buf ffff88022a07fdc0 > fs/cifs/connect.c: CIFS Session Established successfully > fs/cifs/connect.c: file mode: 0x1ed dir mode: 0x1ed > fs/cifs/transport.c: For smb_command 117 > fs/cifs/transport.c: Sending smb: total_len 100 > fs/cifs/connect.c: rfc1002 length 0x3c > fs/cifs/connect.c: disk share connection > fs/cifs/connect.c: nativeFileSystem=FAT32 > fs/cifs/connect.c: Tcon flags: 0x0 > 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 0x52 > fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 3) rc = 0 > fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid: 4 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 0x88 > fs/cifs/cifssmb.c: In GetSrvInodeNum for > fs/cifs/transport.c: For smb_command 50 > fs/cifs/transport.c: Sending smb: total_len 78 > fs/cifs/connect.c: rfc1002 length 0x48 > fs/cifs/inode.c: looking for uniqueid=128957191926360064 > fs/cifs/inode.c: inode 0xffff880225c48d90 old_time=0 new_time=4294953719 > > > Does this tell you anything useful? I could have some other kernel > parameter wrong, but I couldn't begin to imagine what it might be. > A little. Can you try mounting again with "-o noserverino"? Perhaps something is wrong with the inode numbers being generated by the server here... 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 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. -- Jeff Layton <jlayton@...> _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Timothy Normand Miller
::
Rate this Message:
On Fri, Oct 16, 2009 at 10:50 AM, Jeff Layton <jlayton@...> 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? -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Jeff Layton-2
::
Rate this Message:
On Fri, 16 Oct 2009 11:35:07 -0400
Timothy Normand Miller <theosib@...> wrote: > On Fri, Oct 16, 2009 at 10:50 AM, Jeff Layton <jlayton@...> 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@...> _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
|
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Jeff Layton-2
::
Rate this Message:
On Fri, 16 Oct 2009 14:49:56 -0400
Jeff Layton <jlayton@...> wrote: > On Fri, 16 Oct 2009 12:06:59 -0400 > Timothy Normand Miller <theosib@...> 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@...> wrote: > > > On Fri, 16 Oct 2009 11:35:07 -0400 > > > Timothy Normand Miller <theosib@...> wrote: > > > > > >> On Fri, Oct 16, 2009 at 10:50 AM, Jeff Layton <jlayton@...> 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@...> > > > > > > > > > > > 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". > 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@...> From 4f7d1427f79cb26387ee15f5bdec54a3f2bff9fc Mon Sep 17 00:00:00 2001 From: Jeff Layton <jlayton@...> Date: Fri, 16 Oct 2009 15:24:31 -0400 Subject: [PATCH] smb dissector: add support for dissecting SEARCH_ID_FULL_DIR_INFO Signed-off-by: Jeff Layton <jlayton@...> --- epan/dissectors/packet-smb.c | 129 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 129 insertions(+), 0 deletions(-) diff --git a/epan/dissectors/packet-smb.c b/epan/dissectors/packet-smb.c index ec6c26b..98f456a 100644 --- a/epan/dissectors/packet-smb.c +++ b/epan/dissectors/packet-smb.c @@ -10036,6 +10036,7 @@ static const value_string ff2_il_vals[] = { { 0x0102, "Find File Full Directory Info"}, { 0x0103, "Find File Names Info"}, { 0x0104, "Find File Both Directory Info"}, + { 0x0105, "Find File ID Full Directory Info"}, { 0x0202, "Find File UNIX"}, {0, NULL} }; @@ -13935,6 +13936,130 @@ dissect_4_3_4_8(tvbuff_t *tvb _U_, packet_info *pinfo _U_, return offset; } + +static int +dissect_4_3_4_9(tvbuff_t *tvb, packet_info *pinfo, proto_tree *parent_tree, + int offset, guint16 *bcp, gboolean *trunc) +{ + int fn_len, sfn_len; + const char *fn, *sfn; + int old_offset = offset; + proto_item *item = NULL; + proto_tree *tree = NULL; + smb_info_t *si; + guint32 neo; + int padcnt; + + si = (smb_info_t *)pinfo->private_data; + DISSECTOR_ASSERT(si); + + if(parent_tree){ + tvb_ensure_bytes_exist(tvb, offset, *bcp); + item = proto_tree_add_text(parent_tree, tvb, offset, *bcp, "%s", + val_to_str(si->info_level, ff2_il_vals, "Unknown (0x%02x)")); + tree = proto_item_add_subtree(item, ett_smb_ff2_data); + } + + /* + * XXX - I have not seen any of these that contain a resume + * key, even though some of the requests had the "return resume + * key" flag set. + */ + + /* next entry offset */ + CHECK_BYTE_COUNT_SUBR(4); + neo = tvb_get_letohl(tvb, offset); + proto_tree_add_uint(tree, hf_smb_next_entry_offset, tvb, offset, 4, neo); + COUNT_BYTES_SUBR(4); + + /* file index */ + CHECK_BYTE_COUNT_SUBR(4); + proto_tree_add_item(tree, hf_smb_file_index, tvb, offset, 4, TRUE); + COUNT_BYTES_SUBR(4); + + /* dissect standard 8-byte timestamps */ + offset = dissect_smb_standard_8byte_timestamps(tvb, pinfo, tree, offset, bcp, trunc); + if (*trunc) { + return offset; + } + + /* end of file */ + CHECK_BYTE_COUNT_SUBR(8); + proto_tree_add_item(tree, hf_smb_end_of_file, tvb, offset, 8, TRUE); + COUNT_BYTES_SUBR(8); + + /* allocation size */ + CHECK_BYTE_COUNT_SUBR(8); + proto_tree_add_item(tree, hf_smb_alloc_size64, tvb, offset, 8, TRUE); + COUNT_BYTES_SUBR(8); + + /* Extended File Attributes */ + CHECK_BYTE_COUNT_SUBR(4); + offset = dissect_file_ext_attr(tvb, tree, offset); + *bcp -= 4; + + /* file name len */ + CHECK_BYTE_COUNT_SUBR(4); + fn_len = tvb_get_letohl(tvb, offset); + proto_tree_add_uint(tree, hf_smb_file_name_len, tvb, offset, 4, fn_len); + COUNT_BYTES_SUBR(4); + + /* + * EA length. + * + * XXX - in one captures, this has the topmost bit set, and the + * rest of the bits have the value 7. Is the topmost bit being + * set some indication that the value *isn't* the length of + * the EAs? + */ + CHECK_BYTE_COUNT_SUBR(4); + proto_tree_add_item(tree, hf_smb_ea_list_length, tvb, offset, 4, TRUE); + COUNT_BYTES_SUBR(4); + + /* reserved word */ + CHECK_BYTE_COUNT_SUBR(4); + proto_tree_add_item(tree, hf_smb_reserved, tvb, offset, 4, TRUE); + COUNT_BYTES_SUBR(4); + + /* UniqueID */ + CHECK_BYTE_COUNT_SUBR(8); + proto_tree_add_item(tree, hf_smb_index_number, tvb, offset, 8, TRUE); + COUNT_BYTES_SUBR(8); + + /* file name */ + fn = get_unicode_or_ascii_string(tvb, &offset, si->unicode, &fn_len, FALSE, TRUE, bcp); + CHECK_STRING_SUBR(fn); + proto_tree_add_string(tree, hf_smb_file_name, tvb, offset, fn_len, + fn); + COUNT_BYTES_SUBR(fn_len); + + if (check_col(pinfo->cinfo, COL_INFO)) { + col_append_fstr(pinfo->cinfo, COL_INFO, " %s", + format_text(fn, strlen(fn))); + } + + /* skip to next structure */ + if(neo){ + padcnt = (old_offset + neo) - offset; + if (padcnt < 0) { + /* + * XXX - this is bogus; flag it? + */ + padcnt = 0; + } + if (padcnt != 0) { + CHECK_BYTE_COUNT_SUBR(padcnt); + COUNT_BYTES_SUBR(padcnt); + } + } + + proto_item_append_text(item, " File: %s", format_text(fn, strlen(fn))); + proto_item_set_len(item, offset-old_offset); + + *trunc = FALSE; + return offset; +} + /*dissect the data block for TRANS2_FIND_FIRST2*/ static int dissect_ff2_response_data(tvbuff_t * tvb, packet_info * pinfo, @@ -13979,6 +14104,10 @@ dissect_ff2_response_data(tvbuff_t * tvb, packet_info * pinfo, offset = dissect_4_3_4_6(tvb, pinfo, tree, offset, bcp, trunc); break; + case 0x0105: /*Find File ID Full Directory Info */ + offset = dissect_4_3_4_9(tvb, pinfo, tree, offset, bcp, + trunc); + break; case 0x0202: /*Find File UNIX*/ offset = dissect_4_3_4_8(tvb, pinfo, tree, offset, bcp, trunc); -- 1.6.2.5 _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Jeff Layton-2
::
Rate this Message:
On Fri, 16 Oct 2009 16:12:43 -0400
Jeff Layton <jlayton@...> wrote: > On Fri, 16 Oct 2009 14:49:56 -0400 > Jeff Layton <jlayton@...> wrote: > > > On Fri, 16 Oct 2009 12:06:59 -0400 > > Timothy Normand Miller <theosib@...> 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@...> wrote: > > > > On Fri, 16 Oct 2009 11:35:07 -0400 > > > > Timothy Normand Miller <theosib@...> wrote: > > > > > > > >> On Fri, Oct 16, 2009 at 10:50 AM, Jeff Layton <jlayton@...> 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@...> > > > > > > > > > > > > > > > > > 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, I think this will probably fix it. Can you test this patch out and let me know if it does? Thanks, -- Jeff Layton <jlayton@...> From 87f412fa02c9a0ba3eedf964f08efaa67f61edaa Mon Sep 17 00:00:00 2001 From: Jeff Layton <jlayton@...> Date: Fri, 16 Oct 2009 16:42:23 -0400 Subject: [PATCH] cifs: fix server returning zeroed out FileID's in SMB_FIND_FILE_ID_FULL_DIR_INFO It's possible that a server will return a valid FileID when we query the FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers when we do a FindFile with an infolevel of SMB_FIND_FILE_ID_FULL_DIR_INFO. In this situation turn off querying for server inode numbers, and just generate an inode number using iunique. Reported-by: Timothy Normand Miller <theosib@...> Signed-off-by: Jeff Layton <jlayton@...> --- fs/cifs/readdir.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c index 1f098ca..bafef8b 100644 --- a/fs/cifs/readdir.c +++ b/fs/cifs/readdir.c @@ -727,11 +727,13 @@ static int cifs_filldir(char *pfindEntry, struct file *file, filldir_t filldir, cifs_dir_info_to_fattr(&fattr, (FILE_DIRECTORY_INFO *) pfindEntry, cifs_sb); - /* FIXME: make _to_fattr functions fill this out */ - if (pCifsF->srch_inf.info_level == SMB_FIND_FILE_ID_FULL_DIR_INFO) + if (inum) { fattr.cf_uniqueid = inum; - else + } else { fattr.cf_uniqueid = iunique(sb, ROOT_I); + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM) + cifs_sb->mnt_cifs_flags &= ~CIFS_MOUNT_SERVER_INUM; + } ino = cifs_uniqueid_to_ino_t(fattr.cf_uniqueid); tmp_dentry = cifs_readdir_lookup(file->f_dentry, &qstring, &fattr); -- 1.6.0.6 _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
|
|
Re: Can't mount smb shares using mount.cifs with 2.6.31 kernel
by Timothy Normand Miller
::
Rate this Message:
On Fri, Oct 16, 2009 at 3:12 PM, Jeff Layton <jlayton@...> 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 _______________________________________________ linux-cifs-client mailing list linux-cifs-client@... https://lists.samba.org/mailman/listinfo/linux-cifs-client |
| Free embeddable forum powered by Nabble | Forum Help |
