Bug 4176 - can't mount anymore with 2.6.18
Summary: can't mount anymore with 2.6.18
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-16 22:39 UTC by Timothee Besset
Modified: 2006-11-08 17:40 UTC (History)
0 users

See Also:


Attachments
use null domain name if user does not specify (instead of using CIFS_LINUX_DOM) (1.27 KB, patch)
2006-11-07 23:12 UTC, Steve French
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timothee Besset 2006-10-16 22:39:56 UTC
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.
Comment 1 Steve French 2006-11-02 11:08:26 UTC
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)
3) mount
4) "echo 0 > /proc/fs/cifs/cifsFYI" (turn off debugging)
5) "dmesg > tracefile"
6) attach the trace file
Comment 2 Timothee Besset 2006-11-06 12:31:03 UTC
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?
Comment 3 Steve French 2006-11-06 20:36:25 UTC
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.
Comment 4 Steve French 2006-11-06 20:52:17 UTC
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
Comment 5 Steve French 2006-11-07 23:12:57 UTC
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
Comment 6 Steve French 2006-11-08 16:18:09 UTC
Seems non-controversial so I will send this up to mainline fairly soon, and eventually to 2.6.18 point release 
Comment 7 Steve French 2006-11-08 17:40:26 UTC
Made one minor change to the previously attached patch (not critical)