Red Hat Bugzilla – Bug 211753
Can no longer mount windows shares
Last modified: 2007-11-30 17:11:46 EST
Description of problem: I was on 2.6.17-1.2174_FC5. After doing an update {yum} to 2.6.18-1.2200.fc5 I can no longer mount -t cifs to a Windows share. The domain name that is sent to the Windows machine is CIFS_LINUX_DOM even though in the smb.conf it is different {and correct}. Version-Release number of selected component (if applicable): 2.6.18-1.2200.fc5 How reproducible: Very Steps to Reproduce: 1. yum -y update 2. kernel 2.6.17-1.2174_FC5 is removed 3. kernel 2.6.18-1.2200.fc5 is installed. Actual results: When mount -t cifs //server/share /mnt/name -o credentials=/etc/samba.auth.smb returns: mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Checking the event logs on the Windows server - the domain comes across as: CIFS_LINUX_DOM instead of what is in smb.conf {which was working prior to the update}. I googled that domain name and a link: http://www.linuxhq.com/kernel/v2.6/18-rc4/fs/cifs/sess.c has several mentions of that domain name. This happened around the 18th of Oct 2006 after an update and reboot. I tried a before and after test on an FC5 box on vmware with no other changes and the results were the same {Permission deined because of domain name}. Expected results: The mount should have been successful. Additional info:
*** Bug 211754 has been marked as a duplicate of this bug. ***
I am seeing this same behaviour here. Is this bug related to bug 211070 ? It looks like the latest kernel introduced some major issues for CIFS users.
The smb.conf on the client is not used by the cifs client. Instead the domain is passed via mount (e.g. "mount -t cifs //servername/share /mnt -o user=myusername,password=mypassword,domain=mydomainname") As an alternative, if you are using a credentials file on the client, the userid and domain may be specified in it. The cifs code did not change how the domain name was handled, but there were changes to allow specifying older style ("sec=lanman") for handling mounts to older servers, and also a limited support for "ntlmv2" authentication (which works to Samba servers, which are less picky than Windows 200x servers but does not to Windows 200x so it is not attempted by deafult). It is possible that the ntlmv2 change is related, but unlikely. More important may be checking what is specified in the credentials file. Do you specify a domain name in the credentials file? When you specify the correct domain name in the credentials file or on the mount command does it work?
Oops. Putting it in the credentials file does work. Sorry.
mind if we close this out? I don't want to close it, if someone is still running into cifs authorization differences due to changes in kernel versions
Definitely close it. I added the domain into the credentials file and it worked. It is not a bug after all, but a new way something has to be done. People will figure it out or research it. Thanks vm
Was prior kernel versions reading the domain name from smb.conf? Unless it was a previous bug I wouldn't expect the behaviour of SAMBA to change.
cifs vfs (mount.cifs or cifs.ko) never read from smb.conf cifs is configured via settings in the pseudofiles in /proc/fs/cifs, and by mount options passed on the mount command (or equivalent). In the future we would like to able to configure the system to be able to reload /proc/fs/cifs settings at boot time (as in effect you do with smb.conf) but are not aware of a generic way that FC allows sysfs/sysctl and/or proc settings to be configured consistently (yet) and reloaded at boot time.
One thing I will add is that with 2.6.17-1.2187, I am not sure where it got the domain name from. When I mounted a windows share there were at least two events. The first is a logon attempt {EventID: 680} with the account specified in my credentials file and nothing else. The source workstation is logged in the event log with an error code of 0xC0000064 {The account does not exist}. The very next event was a successful network logon. This has the username specified in my credentials file and somehow knew the domain the account is in. I have a small network with one Windows domain & one Solaris nis domain and a stand alone Linux box. I can't find anywhere on the FC5 box that I specified the Windows domain name. My network is on a single subnet so it might broadcast for it. After updating to 2.6.18-1.2200 the first error in the log was the same logon attempt with only the correct logon account and source workstation. This failed {EventID: 680}. The very next security event is a logon failure because of Unknown username or bad password. This is because the domain it tries to authenticate with is CIFS_LINUX_DOM instead of the actual domain where the account exists.
closing re comment #6. thanks.
Although a user should specify a domain name when they mount, even so it should work without it (now in 2.6.19, as before 2.6.18) in many cases (except on 2.6.18) ie the 2.6.19 default domain has been changed to match 2.6.17 (sending a byte of null, instead of "CIFS_LINUX_DOM" as the default domain). Note that cifs in 2.6.17 and earlier sent the default domain as NULL (which almost all servers correctly interpret as "use the [server's] default domain"), this was changed in the cifs client in 2.6.18 to send a default dummy domain name (CIFS_LINUX_DOM) which some versions of windows servers would fail on (some Windows additional servers and clients in a domain will not use the default domain when they get an unknown domain specified on session setup and some will, this would usually not be a problem for standalone machines not in a domain, and for mounting to domain controllers). The patch: http://master.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6e659c63998881e8f4a842edbe86ac8c5cdaee41 fixed it in mainline.
thanks for the pointer steve, I'll queue this for our next update (there'll likely be one more .18 update before we move Fedora to .19) btw, worth sending that for the next 2.6.18.x update perhaps ?