Having just upgraded from 2.6.14 to 2.6.16, I've discovered that I can
no longer mount an SMB share on my network using cifs as the filesystem.
Mounting with smbfs, however, works happily.
I'm using Samba 3.0.21c. The share is served by an Iomega Network
Hard Disk and does not require a password. (Examining the responses
from this thing seems to suggest it's running Samba 2.2.7, which is
quite possibly in violation of the GPL...) The mount options in use
are: defaults,guest,file_mode=0664,dir_mode=0775,gid=users
Turning on tracing in /proc/fs/cifs/cifsFYI gives the following
(slightly anonymised):
fs/cifs/cifsfs.c: Devname: //hostname/NetHDD flags: 64
fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 30 with uid: 0
fs/cifs/connect.c: Username: root
fs/cifs/connect.c: UNC: \\hostname\NetHDD ip: 192.168.x.x
fs/cifs/connect.c: Socket created
fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffff
fs/cifs/transport.c: Sending smb of length 68
fs/cifs/connect.c: Demultiplex PID: 2527
fs/cifs/connect.c: Existing smb sess not found
fs/cifs/transport.c: For smb_command 114
fs/cifs/transport.c: Sending smb of length 47
fs/cifs/connect.c: rfc1002 length 0x82000004)
fs/cifs/connect.c: Good RFC 1002 session rsp
fs/cifs/connect.c: rfc1002 length 0x5b)
fs/cifs/cifssmb.c: share mode security
fs/cifs/connect.c: Security Mode: 0x2 Capabilities: 0xe3f9 Time Zone: 0
fs/cifs/connect.c: In sesssetup
fs/cifs/transport.c: For smb_command 115
fs/cifs/transport.c: Sending smb of length 162
fs/cifs/connect.c: rfc1002 length 0x49)
fs/cifs/connect.c: Guest login
fs/cifs/connect.c: UID = 0
fs/cifs/connect.c: CIFS Session Established successfully
fs/cifs/connect.c: file mode: 0x1b4 dir mode: 0x1fd
fs/cifs/transport.c: For smb_command 117
fs/cifs/transport.c: Sending smb of length 91
fs/cifs/connect.c: rfc1002 length 0x27)
Status code returned 0xc00000cc NT_STATUS_BAD_NETWORK_NAME
fs/cifs/netmisc.c: !!Mapping smb error code 67 to POSIX err -6 !!
fs/cifs/connect.c: CIFS Tcon rc = -6
fs/cifs/cifssmb.c: In SMBLogoff for session disconnect
fs/cifs/transport.c: For smb_command 116
fs/cifs/transport.c: Sending smb of length 39
fs/cifs/connect.c: rfc1002 length 0x2b)
fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 30) rc = -6
CIFS VFS: cifs_mount failed w/return code = -6
Tracing this back to fs/cifs/connect.c seems to suggest that the
relevant difference from 2.6.14 is that the kernel now sends a
hashed password at the start of the smb_command 117, whereas in
the older kernel (and using smbfs) only a null byte is sent for
the password.
I've tried mounting with the sec=none option to turn off password
hashing, but it doesn't seem to make any difference (the request
packet looks about the same in tcpdump as well).
Is there any way to restore the 2.6.14 behaviour, or is this a
bug (or an unimplemented feature) in CIFS? I'm afraid I don't
know anything much about SMB, but I'm happy to provide any
information which might help in tracking this down.
Thanks in advance...
--
Adam Jones ([email protected])(http://www.yggdrasl.demon.co.uk/)
.oO("Shut up! I'm *trying* to concentrate!!!!!" )
PGP public key: http://www.yggdrasl.demon.co.uk/pubkey.asc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
