Bug 215298 - still cifs mount problems (kernel-2.6.18-1.2849.fc6 and kernel-2.6.18-1.2239.fc5smp)
still cifs mount problems (kernel-2.6.18-1.2849.fc6 and kernel-2.6.18-1.2239....
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Layton
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-11-13 05:38 EST by Georg Wittig
Modified: 2014-06-18 03:35 EDT (History)
7 users (show)

See Also:
Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-19 06:13:14 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 Georg Wittig 2006-11-13 05:38:23 EST
Description of problem:
CIFS filesystems are still not mountable.
Worked fine under all kernel versions <= 2187.

Version-Release number of selected component (if applicable)

How reproducible:

Steps to Reproduce:
# mount.cifs //server/directory /cifs -o user=...
  CIFS VFS: Send error in SessSetup = -13 CIFS VFS: cifs_mount failed
  w/return code = -13
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Actual results:
see above

Expected results:
The file system should be mounted.

Additional info:
Same symptom as in kernel-2.6.18-1.2200.fc5.
(see my bugzilla entry no. 211582)
Comment 1 Quentin Spencer 2006-11-16 15:31:16 EST
I'm still seeing this as well with kernel-2.6.18-1.2849.fc6, which I expected
would have fixed it according to the comments in bug #211070. I have not been
able to mount any CIFS shares on any Fedora 2.6.18 kernel yet. I'm currently
running FC6 with the last FC5 2.6.17 kernel.
Comment 2 Georg Wittig 2006-11-17 08:55:13 EST
On the fedora general mailing list (same as the newsgroup
gmane.linux.redhat.fedora.genereal) Garry Williams mentioned a work-around that
did the trick for me on 2849.fc6: Add the "dom=" option to the mount command.
Comment 3 Quentin Spencer 2006-11-17 10:34:16 EST
I tried it and it now works.

I'm not sure whether to still consider this a bug, but at least the change needs
to be documented.
Comment 4 Steve French 2006-11-25 16:57:12 EST
I will add a mention of this in the cifs documentation but I have also changed
it back to using a null domain (rather than default domain) when "dom=" is not
specified.  This will be in 2.6.19.

This bug could be returned
Comment 5 Yves L'ECUYER 2006-12-14 10:54:43 EST
I'm using SAMBA in workgroup environment, Pentium III environment,and I never
got problem until this last kernel 2.6.18-1.2849.fc6 (with
vmlinuz-2.6.18-1.2798.fc6 all was working apparently fine)

Now with no"dom=" parameter, 

if you follow the exchange with ethereal/wireshark analyser you see and
authentification accepted and then a reject with cause "BAD_NETWORK_NAME",
either when you are using a Linux client with mount -t cifs, or when you attach
a network device from a Windows 2000 Pro client.
On the linux client side you can see:
[root@yves131 ~]# mount -t cifs  -o user=yves,dom="" --verbose
// /mnt/tempo 
parsing options: rw,user=yves,dom=
CIFS: invalid domain name
[root@yves131 ~]# mount -t cifs  -o user=yves,dom="afpa" --verbose
// /mnt/tempo 
parsing options: rw,user=yves,dom=afpa

mount.cifs kernel mount options

mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

with dom= parameter I got :
[root@yves131 ~]# mount -t cifs  -o user=yves --verbose //
parsing options: rw,user=yves

mount.cifs kernel mount options
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page
Comment 6 Yves L'ECUYER 2006-12-14 13:44:38 EST
Excuse the mistake in the comment #5 above.
In fact, with or without dom parameter, the authentication works fine (with the
good password !), but the network name is false:
under linux client I got:
[root@yves131 ~]# mount -t cifs  -o user=yves --verbose //
parsing options: rw,user=yves

mount.cifs kernel mount options
retrying with upper case share name

mount.cifs kernel mount options
mount error 6 = No such device or address
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

from a windows client:
I can authenticate correectly to see the shared ressource name, but as soon as I
try to browse the ressource I got an "Unexpected network error".

In both cases (client linux or windows) I got in ethereal trace: a successful
authentication exchange but a BAD_NETWORK_NAME error for the required ressource
PATH (while with all other kernel I tried previously all is working fine)
Comment 7 Ryan Wagoner 2006-12-16 11:17:20 EST
I am having the same issue with 2.6.18-1.2849.fc6 but am getting

CIFS VFS: cifs_mount failed w/return code = -22

I had posted a bugzilla about this before for FC5. You would think by now it
would be fixed. Atleast in FC5 I could mount shares. Now I can't even do that.

My workaround before was to build the smbfs kernel module and smbmnt, smbmount,
smbumount binaries. Guess I will be doing that again for FC6. Why not just
includes smbfs support since CIFS doesn't work properly.

Anybody wanting to do the same see

You will also need to symlink /usr/bin/smbmount to /sbin/mount.smbfs if you want
to just to a mount -t smbfs
Comment 8 Yves L'ECUYER 2006-12-17 14:54:42 EST
Yes the solution you give above is an issue for Linux client machine in front of
Linux Samba server. 

Unfortunately, this is not a solution when you are using a Windows Client
Machine, because samba server doesn't use cifs or smbfs modules.

In fact the main problem is inside the kernel itself, but I have not the
knowledge to search where; as I have already said, with the previous kernel
2.6.18 all was working globally fine.

Today I just try to use the same kernel linux-2.6.18-1.2849.fc6 on my AMD Athlon
64 and Fedora Core 6 x86_64 OS; and on this architecture I dont get any problem.

The device network attachment from a windows client is working fine
the command from a linux client too:
# mount -t cifs //ismf33/public  /mnt/floppy --verbose -o user=user1
parsing options: rw,user=user1

mount.cifs kernel mount options
# df | grep public
//ismf33/public        4316832   3626660    690172  85% /mnt/floppy
Comment 9 Ryan Wagoner 2006-12-17 15:07:27 EST
Unfortunately, this is not a solution when you are using a Windows Client
Machine, because samba server doesn't use cifs or smbfs modules.


I don't think you understand. The cifs and smbfs modules are used to mount
shares located on remote machines.

I have a Windows 2003 Server with multiple shares. Doing a mount -t cifs I can
not access these shares. After building the smb* binaries and smbfs module I can
do a mount -t smbfs and access these shares.

When I have gotten them to mount with cifs, after a day or two files with no
extensions were not accessible. In my opinion cifs has terrible support under
kernels 2.6.18*

If you are talking about accessing samba shares from a Windows client that has
always worked perfectly and still does.
Comment 10 Yves L'ECUYER 2006-12-18 13:34:41 EST
OK it's clear now.

Personally I have no windows 2003 server in my current environment,so i didn't
encounter this misbehavior till now, but I will try tomorrow at office with my
collegues working on Win2003 environment.

Well in fact all my troubles with the i686/32bits machines related previously,
came from a erroneous change in SELINUX policy (from disabled to enforcing), and
not from a kernel upgrade. So now all my standard environment is working fine again
Comment 11 Joachim Backes 2007-01-22 01:55:00 EST
Having similar problem with FC6 (2.6.19-1.2895.fc6):

mount -t cifs //fp1/shares /mnt -o user=.....,ip=.....,dom=.....
mount error 22 = Invalid argument
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

On Windows site, win2003 server rel. 2 is running.
Comment 12 Jeff Layton 2007-11-18 07:55:46 EST
Is this still an issue on more recent kernels and mount.cifs? If so, could you
turn up cifsFYI when mounting and get dmesg output from it?

# modprobe cifs
# echo 7 > /proc/fs/cifs/cifsFYI
# mount...

..after it fails:

# dmesg > /tmp/dmesg.out

and then attach dmesg.out to this BZ.
Comment 13 Joachim Backes 2007-11-19 01:22:35 EST
Retrying under F7: problem has disappeared. Now I can mount the cifs directory
(I did not any try under F8).

May be closed.

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