Bug 7209

There was one report of the domain name not being specified on mount
automatically in 2.6.18 (we can not think of a reason why, since cifs has always
required a domain name to be specified on mount, not via smb.conf as with smbfs).

The one report that was vaguely similar, asserted that adding the
"domain=myserverdomainname" (to the list of mount options specified on the
client) worked.

Although that seems unlikely, could you try that?

Otherwise, let us try the usual and see if enabling debugging
"echo 1 > /proc/fs/cifs/cifsFYI"
before the mount (and looking at output of "dmesg" or equivalent)
shows whether the "session setup" (authentication) failed (server does not
understand the userid/password) or whether the "tree connection" or subsequent
stat failed (no access for that valid user to that directory on the server)

Adding domain=xx works.  This wasn't required in 2.6.17.
Note that I still don't have to set domain=xx for
mounting my Windows 2K3 site server.  Why does
that still work?  Anyway, I'm good to go, thanks.

Any chance you could do a quick ethereal trace of mount from 2.6.17 client
(works) and mount from 2.6.18 client (fail) and mount from 2.6.18 client with
domain specified (works) - all to the same server?

Attaching an ethereal or tcpdump trace would allow me to see what is differing
on the wire between the two.

Presumably the reason that mounting to a Windows 2003 server would work (if it
is a domain contorller) is that it has a local copy of the user database and
thus can authenticate the user/password - while on the client (if it is
configured to be a member of the Windows 2003 domain) it has no local copy of
that user - and thus needs to know the correct domain name of the user in order
to authenticate it.

I'm also encountering the mentioned problem.
I'm trying to mount an active directory share using the CIFS protocol, but
I keep getting a permission denied. The same setup using a kernel older than
2.6.18 doesn't show the problem.

Attached are 2 wireshark traces, both from a 2.6.18 kernel (I'll try
to create one from a 2.6.17 kernel also).

Created attachment 9377 [details]
Wireshark trace of mounting a CIFS share 'the normal way'

Created attachment 9378 [details]
Wireshark trace of mounting a CIFS share using the domain= option

Here is some more debug info

Normal mount:
 fs/cifs/cifsfs.c: Devname: //FILE01/Users flags: 64 
 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 36407 with uid: 0
 fs/cifs/connect.c: Username: epienbro 
 fs/cifs/connect.c: UNC: \\FILE01\Users ip: 145.48.129.26
 fs/cifs/connect.c: Socket created
 fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffff
 fs/cifs/connect.c: Demultiplex PID: 3500
 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 of length 67
 fs/cifs/connect.c: rfc1002 length 0x6d)
 fs/cifs/cifssmb.c: Dialect: 1
 fs/cifs/cifssmb.c: negprot rc 0
 fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x1f3fd Time Zone: 65476
 fs/cifs/sess.c: sess setup type 1
 fs/cifs/transport.c: For smb_command 115
 fs/cifs/transport.c: Sending smb:  total_len 278
 fs/cifs/connect.c: rfc1002 length 0x27)
 fs/cifs/netmisc.c:  !!Mapping smb error code 5 to POSIX err -13 !!
 fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
 fs/cifs/sess.c: ssetup rc from sendrecv2 is -13
 fs/cifs/sess.c: ssetup freeing small buf db72c300
 CIFS VFS: Send error in SessSetup = -13
 fs/cifs/connect.c: No session or bad tcon
 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 36407) rc = -13
 CIFS VFS: cifs_mount failed w/return code = -13

Mount using domain option:
 fs/cifs/cifsfs.c: Devname: //FILE01/Users flags: 64 
 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 36408 with uid: 0
 fs/cifs/connect.c: Domain name set
 fs/cifs/connect.c: Username: epienbro 
 fs/cifs/connect.c: UNC: \\FILE01\Users ip: 145.48.129.26
 fs/cifs/connect.c: Socket created
 fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffff
 fs/cifs/connect.c: Demultiplex PID: 3506
 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 of length 67
 fs/cifs/connect.c: rfc1002 length 0x6d)
 fs/cifs/cifssmb.c: Dialect: 1
 fs/cifs/cifssmb.c: negprot rc 0
 fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x1f3fd Time Zone: 65476
 fs/cifs/sess.c: sess setup type 1
 fs/cifs/transport.c: For smb_command 115
 fs/cifs/transport.c: Sending smb:  total_len 262
 fs/cifs/connect.c: rfc1002 length 0xbb)
 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 = 63488 
 fs/cifs/sess.c: bleft 142
 fs/cifs/sess.c: words left: 0
 fs/cifs/sess.c: ssetup freeing small buf db72c700
 fs/cifs/connect.c: CIFS Session Established successfully
 fs/cifs/connect.c: file mode: 0x7f7  dir mode: 0x1ff
 fs/cifs/transport.c: For smb_command 117
 fs/cifs/transport.c: Sending smb of length 80
 fs/cifs/connect.c: rfc1002 length 0x42)
 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 of length 68
 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 of length 68
 fs/cifs/connect.c: rfc1002 length 0x50)
 fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 36408) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_read_inode as Xid: 36409 with uid: 0
 fs/cifs/inode.c: Getting info on 
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb of length 74
 fs/cifs/connect.c: rfc1002 length 0x94)
 fs/cifs/inode.c: Old time 0
 fs/cifs/inode.c: New time 333059
 fs/cifs/inode.c: Directory inode
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 36410 with uid: 0
 fs/cifs/inode.c: Revalidate:  inode 0xc7a08d74 count 1 dentry: 0xd01389c4
d_time 0 jiffies 333313
 fs/cifs/inode.c: Getting info on 
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb of length 74
 fs/cifs/connect.c: rfc1002 length 0x94)
 fs/cifs/inode.c: Old time 333059
 fs/cifs/inode.c: New time 333313
 fs/cifs/inode.c: Directory inode
 fs/cifs/inode.c: cifs_revalidate - inode unchanged
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 36410) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 36411 with uid: 0
 fs/cifs/inode.c: Revalidate:  inode 0xc7a08d74 count 1 dentry: 0xd01389c4
d_time 0 jiffies 333316
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 36411) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 36412 with uid: 0
 fs/cifs/inode.c: Revalidate:  inode 0xc7a08d74 count 1 dentry: 0xd01389c4
d_time 0 jiffies 333316
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 36412) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 36413 with uid: 0
 fs/cifs/inode.c: Revalidate:  inode 0xc7a08d74 count 1 dentry: 0xd01389c4
d_time 0 jiffies 333316
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 36413) rc = 0
 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 36414 with uid: 0
 fs/cifs/inode.c: Revalidate:  inode 0xc7a08d74 count 1 dentry: 0xd01389c4
d_time 0 jiffies 333316
 fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 36414) rc = 0

The fix for not requiring "domain=" on the mount (in most cases) has been in the
kernel for a while now (certainly in 2.6.20).

The issue was that when cifs session setup was rewritten it "fixed" a bug in how
the domain name was setup - but had a sideeffect that the default domain name on
session setup was no longer sent as "null" (which the server would interpret as
"use my own [server's] domain to try to authenticate this user"), but as a default
(generic) domain name.

You should probably always specify the domain name on mount to be precise, but
I agreed that in most cases the server and client are in the same domain and
the better behavior is to send an empty domain rather than default/bogus domain
name when the user does not type this.
when the user specified

Sorry this took so long to find this defect, it was reported in a different
bugzilla and fixed  back in early November.
http://master.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6e659c63998881e8f4a842edbe86ac8c5cdaee41