Description of problem: CIFS filesystems are still not mountable. Worked fine under all kernel versions <= 2187. Version-Release number of selected component (if applicable) kernel-2.6.18-1.2239.fc5smp kernel-2.6.18-2849.fc6 How reproducible: Always 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)
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.