Red Hat Bugzilla – Bug 218228
CIFS Permission denied error on 2.6.18-1.2849
Last modified: 2007-11-30 17:11:50 EST
Description of problem:
CIFS read error on fresh FC6 installation Kernel 2.6.18-1.2849.fc6. File is
mounted by fstab from a FC5 SMB share, mounted by the below:
//192.168.1.41/main /main cifs
users,uid=500,gid=500,username=??????,password=?????? 0 0
Error display from console:
cp: reading `/main/uploads/somefile': Permission denied
Same file above shows up fine in Nautilus but am unable to copy, open, read,
Same file using same username/pass same file location from WinXP machine has no
Version-Release number of selected component (if applicable):
Kernel=2.6.18-1.2849.fc6 on client machine
Kernel=2.6.15-1.2054_FC5 on SMB Server
Steps to Reproduce:
1. Mount CIFS Share with FC6 Kernel
2. Try to copy/read/open/ etc any file
On the FC6 client machine, can you mount the share, issue commands
echo 1 > /proc/fs/cifs/cifsFYI
issue either copy or read or open command for a file and then send dmesg log.
You may also want to issue command
echo 1 > /proc/fs/cifs/traceSMB
besides the above listed echo command.
Are you running samba server on the FC5 server? If so, what is the version
of samba server? And for the same file that you intend to either copy or
read or write from the client, can you please also state the permissions i.e.
ls -l <file_name>
on the server?
Created attachment 143224 [details]
Sorry, this goes with the above:
[root@localhost ~]# rpm -qa samba*
[root@localhost ~]# ls -l /main/test.file
-rwxrwxrwx 1 root root 1073741824 Sep 21 08:31 /main/test.file
So for a read request (0x2e),
fs/cifs/cifssmb.c: Reading 16384 bytes on fid 8379
fs/cifs/transport.c: For smb_command 46
fs/cifs/transport.c: Sending smb: total_len 63
| 0x00 0x00 0x00 0x3b 0xff 0x53 0x4d 0x42 | _ _ _ ; � S M B
| 0x2e 0x00 0x00 0x00 0x00 0x00 0x01 0xd0 | . _ _ _ _ _ _
error 5 (ERRnoaccess) is returned by the server.
fs/cifs/netmisc.c: !!Mapping smb error code 5 to POSIX err -13 !!
fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
CIFS VFS: Send error in read = -13
fs/cifs/file.c: Read error in readpages: -13
fs/cifs/file.c: CIFS VFS: leaving cifs_readpages (xid = 1879) rc = -13
fs/cifs/file.c: CIFS VFS: in cifs_readpage as Xid: 1880 with uid: 500
fs/cifs/file.c: readpage c1219520 at offset 0 0x0
It is strange Samba server would return ERRnoaccess for a file with
Looking at the trace for more details.
I believe this is a Kernel bug. CIFS has been broken ever since .2200 FC5 kernel.
All of these file read/write/list fine from a Windoze machine from the same
What is the version of cifs.ko that is running on the machine that is running
Just for my clarification, when a Windows machine mounts the very same share
from the very same samba server, you can read/write/list files fine from a that
Windows client machine but when a cifs client is used on a linux FC6 machine to
mount the very same share from the very same samba server, you encounter this
In other words, a similar trace on Windows client machine will not show
the ERRnoaccess error.
[root@localhost garage]# cat /sys/module/cifs/version
You are correct, same file from same share on a windoze machine works fine.
Only a problem on the FC6 Machine.
Just for the sake of trying, if you use mount -t smbfs instead of mount -t cifs,
do you encounter same problem on FC6 box?
Thanks, smbfs has been removed from the Fedora kernels since core ~5, cannot test.
OK. Besides delving deeper into the log sent to decipher, it would take me at
least couple of days before I can install FC6 on a box to use as a cifs client.
Meanwhile, so I can repeat the steps you take, basically after mounting
filesystem, what command do you issue for test.file?
ls -l /main/test.file
cp /main/test.file xyz
or something else?
Yep, update to the 2849 kernel and attempt to cp any file from the remote smb share.
Not sure what did it, but I've upgrade my server to FC6 and my client box to
FC6 kernel 2.6.18-1.2868.fc6 and I no longer have this problem.
Thanks for the help! I'm guessing this is still a valid bug for the existing
Closing bug based on comment #12