I use several shares hosted on Windows 2003 servers. Nothing has changed on the servers, but since Debian Sid moved to kernel 2.6.18-1, the mounts fail. With 2.6.17 things were working just fine.
# mount --verbose /mnt/home
parsing options: rw,noauto,user=timo,uid=1000,gid=1000
mount.cifs kernel mount options unc=//***************\home,ip=10.4.20.3,pass=******,ver=1,rw,noauto,user=timo,uid=1000,gid=1000
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
I saw on the website that CIFS 1.45 is in 2.6.18, and that sounds like quite a change. Unfortunately it doesn't seem to be backwards compatible. I can investigate some more and provide more information but I will need directions.
Ideally I need to see a comparison of ethereal (aka "wireshark") traces of the 2.6.17 vs. 2.6.18 cases (one fails, one works) - alternatively a trace of the failing mount vs. the good mount might be sufficient.
Before the mount:
1) "dmesg -c" (clear the message buffer)
2) "echo 7 > /proc/fs/cifs/cifsFYI" (turns on various debugging flags)
4) "echo 0 > /proc/fs/cifs/cifsFYI" (turn off debugging)
5) "dmesg > tracefile"
6) attach the trace file
Ok I can work on that. I don't want to leak any sensitive login/password information in the report though. How safe am I from that perspective?
To avoid exposing any account information, you could use a new account for this test/trace and delete the account when you are done. In addition you could send the trace file directly rather than in a public defect.
Looks like the working one is sending a domain string of null (one byte of '\0') so the server would consider this the default domain (its own) - what is happening is that it is getting set to CIFS_LINUX_DOM instead in newer kernels which means that the server does not recognize it as its own domain anymore
Created attachment 2200 [details]
use null domain name if user does not specify (instead of using CIFS_LINUX_DOM)
patch to use null domain (as we used to) rather than the bogus default domain CIFS_LINUX_DOM - when the user forgets to specify the domain on the mount
Seems non-controversial so I will send this up to mainline fairly soon, and eventually to 2.6.18 point release
Made one minor change to the previously attached patch (not critical)