Bug 211753 - Can no longer mount windows shares
Can no longer mount windows shares
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
: 211754 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-10-21 17:39 EDT by vaughn miller
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-20 14:19:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description vaughn miller 2006-10-21 17:39:02 EDT
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):

How reproducible:

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
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:
Comment 1 Dave Jones 2006-10-21 18:02:40 EDT
*** Bug 211754 has been marked as a duplicate of this bug. ***
Comment 2 Danny D'Amours 2006-10-23 10:31:55 EDT
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.
Comment 3 Steve French 2006-10-23 12:11:21 EDT
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

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?
Comment 4 vaughn miller 2006-10-23 16:32:40 EDT
Oops. Putting it in the credentials file does work. 

Comment 5 Steve French 2006-10-23 16:50:35 EDT
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 
Comment 6 vaughn miller 2006-10-23 19:59:24 EDT
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.


Comment 7 Danny D'Amours 2006-10-24 08:56:57 EDT
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.
Comment 8 Steve French 2006-10-24 10:27:47 EDT
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.
Comment 9 vaughn miller 2006-10-24 17:24:05 EDT
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.
Comment 10 Dave Jones 2006-11-20 14:19:12 EST
closing re comment #6.

Comment 11 Steve French 2006-11-20 15:09:25 EST
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:


fixed it in mainline.
Comment 12 Dave Jones 2006-11-20 15:29:11 EST
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 ?

Note You need to log in before you can comment on or make changes to this bug.