Bug 215298

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.

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.

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.

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

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
//192.168.20.131/public /mnt/tempo 
parsing options: rw,user=yves,dom=
CIFS: invalid domain name
[root@yves131 ~]# mount -t cifs  -o user=yves,dom="afpa" --verbose
//192.168.20.131/public /mnt/tempo 
parsing options: rw,user=yves,dom=afpa
Password: 

mount.cifs kernel mount options
unc=//192.168.20.131\public,ip=192.168.20.131,pass=iso9660,ver=1,rw,user=yves,dom=afpa

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 //192.168.20.131/public
/mnt/tempo 
parsing options: rw,user=yves
Password: 

mount.cifs kernel mount options
unc=//192.168.20.131\public,ip=192.168.20.131,pass=iso14000,ver=1,rw,user=yves 
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page

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 //192.168.20.131/public
/mnt/tempo 
parsing options: rw,user=yves
Password: 

mount.cifs kernel mount options
unc=//192.168.20.131\public,ip=192.168.20.131,pass=iso9000,ver=1,rw,user=yves 
retrying with upper case share name

mount.cifs kernel mount options
unc=//192.168.20.131\PUBLIC,ip=192.168.20.131,pass=iso9000,ver=1,rw,user=yves 
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)

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
http://www-user.tu-chemnitz.de/~tott/FC5-smbfs-HOWTO.html

You will also need to symlink /usr/bin/smbmount to /sbin/mount.smbfs if you want
to just to a mount -t smbfs

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
and
the command from a linux client too:
*********************************
# mount -t cifs //ismf33/public  /mnt/floppy --verbose -o user=user1
parsing options: rw,user=user1
Password: 

mount.cifs kernel mount options
unc=//ismf33\public,ip=192.168.200.33,pass=iso9000,ver=1,rw,user=user1
# df | grep public
//ismf33/public        4316832   3626660    690172  85% /mnt/floppy
**********************************

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.

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

Having similar problem with FC6 (2.6.19-1.2895.fc6):

mount -t cifs //fp1/shares /mnt -o user=.....,ip=.....,dom=.....
Password: 
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.

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.

Retrying under F7: problem has disappeared. Now I can mount the cifs directory
(I did not any try under F8).

May be closed.