When two different users mount the same Windows 2003 Server share using CIFS, the first session mounted will be invalidated. How to reproduce: - configure an "open share" (full permissions to Guest user) on Windows 2003 Server (I couldn't reproduce the problem with Samba server or Windows older than 2003) - the server probably must not be domain controller or domain member server - mount the share twice with different users (tested with mainline cifs.ko): # mount -t cifs //server/share /mnt/a -o noacl,noperm,user=john,dir_mode=0700,domain=DOMAIN,rw # mount -t cifs //server/share /mnt/b -o noacl,noperm,user=jeff,dir_mode=0700,domain=DOMAIN,rw Result: - just the mount point mounted last is accessible: client:/mnt # ls -la ls: cannot access a: Permission denied total 8 drwxr-xr-x 4 root root 4096 Dec 9 19:14 . drwxr-xr-x 31 root root 4096 Dec 15 11:40 .. d????????? ? ? ? ? ? a drwx------ 1 root root 0 Dec 15 2008 b - "net session" output from the server: Computer User name Client Type Opens Idle time ------------------------------------------------------------------------------- 192.168.8.1 GUEST Linux version 2.6 0 000012 - I can't reproduce the problem with Windows 2000 Server.
Created attachment 3838 [details] Traffic capture when mounting Windows 2000 Server share
Created attachment 3839 [details] Logs from CIFS when mounting Windows 2000 Server share
Created attachment 3840 [details] Traffic capture when mounting Windows 2003 Server share
Created attachment 3841 [details] Logs from CIFS when mounting Windows 2003 Server share
I spent some time investigating this problem and I couldn't discover yet the answer for the following question: What variables, parameters or commands different versions of Windows puts in the equation when deciding if a new SMB session should be created? I ask this because comparing the traffic between the CIFS client and Windows 2000 and 2003 servers, I couldn't find any significant difference. As the same CIFS client is being used, I assume something changed between Windows 2000 and 2003 regarding SMB sessions. I also did some experiments with CIFS code and got one result that might be useful. If I apply the following only-for-debug-purpose-patch, effectively disabling the sharing of TCP connections to the same server, the original problem disappears: --- linux.orig/fs/cifs/connect.c +++ linux/fs/cifs/connect.c @@ -1463,9 +1463,11 @@ cifs_get_tcp_session(struct smb_vol *vol } /* see if we already have a matching tcp_ses */ +#if 0 tcp_ses = cifs_find_tcp_session(&addr); if (tcp_ses) return tcp_ses; +#endif tcp_ses = kzalloc(sizeof(struct TCP_Server_Info), GFP_KERNEL); if (!tcp_ses) { It's interesting that Windows 2003 Server still shows only one SMB session on "net session" output. "netstat -an" shows two connections to port 445, confirming that the TCP connection is not being shared. This made me think that a parameter like the source port isn't being used to decide that a new session is needed.
Can you try the mount commands with just -o user=abc and -o user=def i.e. without any other mount options? I am also puzzled by the output of command 'net session' on windows 2003 server when you have mounted shares as users jeff and john. This is the output of 'net session' command on Windows 2003 server Computer User name Client Type Opens Idle time -------------------------------------------------------------------------------123.345.678.9 ADMINISTRATOR Linux version 2.6 0 00:01:17 123.345.678.9 NEWUSER1 Linux version 2.6 0 00:01:21 And output of mount command on the cifs client machine with cifs.ko 1.55 //abc.def.ghi.com/public on /mnt/smb_s type cifs (rw,mand) //abc.def.ghi.com/public on /mnt/smb_t type cifs (rw,mand) And I used the exact same options during mount that you have user during mount. Also, the share public has Full Control (Permissions) for 'Guests'
Shirish, thanks for taking a look at this. > Can you try the mount commands with just -o user=abc and -o user=def > i.e. without any other mount options? I tried and the results are the same for me (the problem persists). > 123.345.678.9 ADMINISTRATOR Linux version 2.6 0 00:01:17 > 123.345.678.9 NEWUSER1 Linux version 2.6 0 00:01:21 Probably this is working for you because "ADMINISTRATOR" and "NEWUSER1" are valid users in your Windows 2003 Server. In my example, Windows 2003 Server doesn't know "jeff" and "john". I know this is weird, but unfortunately I can't change anything in the Windows Server.
What user are you (# whoami) when you issue mount command on the linux box? And were you not prompted for password when you issued the mount commands as user=jeff and user=john? What is the output of the mount command on the linux box? I looked at the wireshark traces and session setup has user Leonardo as user. How does john, jeff, Leonardo, GUEST tie up together, I am not sure!
Windows 2003 server does not allow Windows client GUEST logins with more than one user name C:\>net use y: \\cifstest1\public /USER:abc The command completed successfully. C:\>net use New connections will be remembered. Status Local Remote Network ------------------------------------------------------------------------------- OK Y: \\cifstest1\public Microsoft Windows Network The command completed successfully. C:\>net use z: \\cifstest1\public /USER:def System error 1219 has occurred. Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again..
(In reply to comment #8) > What user are you (# whoami) when you issue mount command on the linux box? I was logged as root when I did the tests. > And were you not prompted for password when you issued the mount commands > as user=jeff and user=john? Yes, but any password will work. > What is the output of the mount command on the linux box? # mount output: //192.168.8.142/Shared on /smb/a type cifs (rw,mand) //192.168.8.142/Shared on /smb/b type cifs (rw,mand) # /proc/mounts: //192.168.8.142/Shared /smb/a cifs rw,mand,unc=\\192.168.8.142\Shared,username=jeff,uid=0,gid=0,rsize=16384,wsize=57344 0 0 //192.168.8.142/Shared /smb/b cifs rw,mand,unc=\\192.168.8.142\Shared,username=john,uid=0,gid=0,rsize=16384,wsize=57344 0 0 > I looked at the wireshark traces and session setup has user Leonardo as > user. How does john, jeff, Leonardo, GUEST tie up together, I am not sure! I'm sorry for the mix up. In the original bug description I used "john" and "jeff" as the user names to mount the volumes. When I was generating the data to attach here, I used the user names "Leonardo" and "Tester" instead of "john" and "jeff".
(In reply to comment #9) > Windows 2003 server does not allow Windows client GUEST logins with > more than one user name > > C:\>net use y: \\cifstest1\public /USER:abc > The command completed successfully. (...) > C:\>net use z: \\cifstest1\public /USER:def > System error 1219 has occurred. Shirish, useful information, thanks! I did some tests again here and found why we are seeing different results. ** Server: Windows 2003 Server, Client: Windows 2000 Server - First test: Logged on W2k Server as "Leonardo": C:\>net use y: \\192.168.8.142\shared /user:john The command completed successfully. C:\>net use z: \\192.168.8.142\shared /user:jeff System error 1219 has occurred. The credentials supplied conflict with an existing set of credentials. Same error as you just reported. I suppose this error came from the "client side" and not from the Windows 2003 Server. - Second test: Logged on W2k Server as "Leonardo": C:\>net use y: \\192.168.8.142\shared /user:john The command completed successfully. Logged again on the same W2k Server (I'm using rdesktop) as "Administrator": C:\>net use z: \\192.168.8.142\shared /user:jeff The command completed successfully. At this point you'll have two sessions opened in the Windows 2003 Server: Computer User name Client Type Opens Idle time ------------------------------------------------------------------------------- \\192.168.8.141 GUEST Windows 2000 2195 0 00:00:09 \\192.168.8.141 GUEST Windows 2000 2195 0 00:00:14
> Shirish, useful information, thanks! > System error 1219 has occurred. > The credentials supplied conflict with an existing set of credentials. > Same error as you just reported. I suppose this error came from the "client > side" and not from the Windows 2003 Server. I think so too, that the error is coming from client side. I repeated the same against a samba share and same error. The wireshark traces indicate that it is the client side that generates the error.
Windows as a client behave same way, the error 1219 occurred when the SMB/CIFS client was Windows XP and Windows 2003 Server. I was able to use Windows XP to do what you want to do. So something has changed in Windows 2003 Server. Do you still think this is a a cifs vfs client bug/problem?
The Windows 2003 and Windows 2000 network traces both show that both users are being authenticated as "guest" (see the Action field in the SMB SessionSetup response) ... so this implies that they are not recognized as the user that you think that they are. Perhaps Windows made a security setting change in Windows 2003 to only allow one "guest" connection from the same source ip address (client)? In the Windows 2003 case, the two smb uids are 4097 and 4098 - after the 2nd session setup the earlier smb uid is apparently invalidated since Windows returns "bad userid" on the formerly good smb uid 4097. Presumably there is a Windows setting to control this authentication behavior.
(In reply to comment #14) When I mounted the share third time at different mount point, the first two instances were invalidated. [root@sysem ~]# ls -l /mnt total 4 ?--------- ? ? ? ? ? /mnt/smb_a drwxrwxrwx 1 root root 0 Jan 15 11:28 smb_b drwxrwxrwx 1 root root 0 Jan 15 11:28 smb_c And I think this applies only to GUEST user, when I repeated above for a valid user Administrator, mounts looked fine. [root@system ~]# ls -l /mnt total 4 drwxrwxrwx 1 root root 0 Jan 15 11:28 smb_a drwxrwxrwx 1 root root 0 Jan 15 11:28 smb_b drwxrwxrwx 1 root root 0 Jan 15 11:28 smb_c
(In reply to comment #13) There is no system error 1219 if the user is a valid user (e.g. user=Administrator). I think Windows client remembers to enforce one GUEST login per session (or something like that) and now Windows severs (have started) enforcing that.
> I was able to use Windows XP to do what you want to do. So something has > changed in Windows 2003 Server. Do you still think this is a a cifs vfs client > bug/problem? While I completely agree with with you that something changed with Windows 2003 Server, I have to say that when I use a Windows XP client, I'm able to map the same Windows 2003 Server share twice with different users. This made me think that it could be a problem in CIFS. Indeed, I still think it is, but now I think it probably can't be fixed (more comments to follow).
Created attachment 3895 [details] Traffic capture of Win XP (client) mapping W2k3 shares (server) The attached traffic capture happened between Windows XP (client) and Windows 2003 Server (server), when executing the following steps: 1. Logged in twice in Windows XP using the "Switch User" functionality. 2. With the first user, executed in the command prompt: net use z: \\192.168.8.142\shared /u:john 3. Switched immediately to the second user and executed in the command prompt: net use y: \\192.168.8.142\shared /u:jeff 4. Switched back to first user and executed "dir" on z: 5. Switched to second user and executed "dir" on y: 6. Powered off the client
> Indeed, I still think it is, but now I think it probably can't be > fixed (more comments to follow). The reason behind this statement is that, when looking at the traffic capture I just attached, I thought Windows XP was closing the SMB session when I switched users, but it seems that this is not true and just IPC$ sessions are being closed. I'm sorry for the confusion and thanks a lot for all the time you are investing in this problem.
I do not know what cifs client can do when the very same user id returned by Windows 2003 server during session setup is treated as a bad user id by Windows 2003 server.
(In reply to comment #17) > when I use a Windows XP client, I'm able to map the > same Windows 2003 Server share twice with different users. But see, you are different user, I do not know how it is in Windows but it is different user sessions and Windows SMB/CIFS client restrict one GUEST login per user session and now Windows SMB/CIFS servers (have started) enforcing one GUEST login per connection (i/p address) On a linux box, I logged on as root on two different pty's and tried to mount the same share from a Windows 2003 server on two different mount points from two different ptys as root and run into same problem (one GUEST login per connection (i/p address)).
(In reply to comment #11) > - Second test: > Logged on W2k Server as "Leonardo": > C:\>net use y: \\192.168.8.142\shared /user:john > The command completed successfully. > Logged again on the same W2k Server (I'm using rdesktop) as "Administrator": > C:\>net use z: \\192.168.8.142\shared /user:jeff > The command completed successfully. > At this point you'll have two sessions opened in the Windows 2003 Server: > Computer User name Client Type Opens Idle time > ------------------------------------------------------------------------------- > \\192.168.8.141 GUEST Windows 2000 2195 0 00:00:09 > \\192.168.8.141 GUEST Windows 2000 2195 0 00:00:14 Instead of logging as Leonardo and Administrator (using remote desktop), if you (again) login as Leonardo (using remote desktop), what happens? Do you see two GUEST logins on the Windows 2003 server?
Created attachment 3899 [details] patch to alter how cifs sends the vcnumber to see if windows will recognize 2nd guest connection
If this patch helps, let me know ASAP
(In reply to comment #24) > If this patch helps, let me know ASAP Steve, thank you! With your patch, I'm now able to mount the same Windows 2003/2008 Server share multiple times with different users. I also tested Windows 2000 and it keeps working as before. Now, on 2003 Server, two SMB sessions are created: Computer User name Client Type Opens Idle time ------------------------------------------------------------------------------- \\192.168.8.1 GUEST Linux version 2.6 0 00:00:04 \\192.168.8.1 GUEST Linux version 2.6 0 00:00:04 Again, thanks a lot!
Created attachment 3947 [details] patch to alter how cifs sends the vcnumber now also handles reconnect The patch has been updated to handle reconnect better (always starts reconnect with vcnumber 0)
Patch now in official 2.6.29-rc tree