Description of problem: Cannot edit, cat, or copy files from a Windows 2003 Domain Controller running Service Pack 1 using mount.cifs under FC5. I am able to mount the share, I am able to create new files, and I am able to delete files. However, once I create a file and put some data into the file, I can no longer edit the file, or copy it without receiving a Permission Denied message. Within vi, it says READ ERRORS at the bottom when in the file. However, I can delete the file. Version-Release number of selected component (if applicable): kernel 2.6.15-1.2054_FC5 #1, samba-client-3.0.21b-2 How reproducible: From a standard load of FC5. Using a Windows 2003 Server which is running Service Pack 1 and is configured as a domain controller for an Active Directory domain. Steps to Reproduce: 1. mkdir /mntpoint 2. mount.cifs //server/share /mntpoint -o username=domain_admin_acct 3. cd /mntpoint 4. echo foo > file1.txt 5. cat file1.txt Actual results: cat: file1.txt: Permission denied Expected results: foo Additional info: I see this in /var/log/messages when I try to cat the file; kernel: CIFS VFS: Send error in read = -13 This works fine from FC4 boxes, and I can see foo from FC4 as well as from the Windows machine via notepad. And I can type; rm file1.txt and the file is deleted (so this shouldn't be a permissions problem)
This problem does not seem to occur when the 2003 Server is a member server, only when it's a domain controller.
I have confirmed this same issue. All Windows 2003 AD controllers are effected, member servers on the domain are not. It seems related to the group policy option "Domain member: Digitally encrypt or sign secure channel data" which is enabled by default (Windows settings - > security settings -> local policies -> security options). This worked fine with mount.cifs in FC4 and FC3, with FC5 it does not.
I also have this issue but with fc4.
It looks like there is something wrong with the kernel/cifs module. I rebooted my FC4 machine to kernel 2.6.15-1.1833_FC4 and samba appears to be working again. Admittedly I only tested it for about 30 seconds but the errors are gone and I can read files on the w2k3 file system again. I wonder if there is an older kernel available for FC5 that might work?
hummmmm, could this be the problem: http://www.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commit;h=e9917a000fcc370408c8b7b83f2e85dba5fffbd4
Well, the problem has been fixed in kernel-2.6.16-1.2096_FC5. Nice to see that the status of this bug is still NEW and absolutely nothing noted here about any fix. I got wind of the fix from www.fedoraforum.org. Thanks to those forum members for updating my original post when this kernel release came out.
I am seeing exactly the same symptoms as described in the original report of this bug. However, the files I am trying to read are on an FC5 samba server running samba-3.0.23a-1.fc5.1, with kernel 2.6.17-1.2157_FC5 on the server and 2.6.17-1.2145_FC5 on the client (I'll reboot the client soon to 2.6.17-1.2157_FC5 but I suspect it'll make no difference).
I also am experiencing identical symptoms as the original poster, using kernel 2.6.17-1.2157_FC5, samba-3.0.23a-1.fc5.1 on both client and server. So clearly the problem hasn't gone away, or has been reintroduced. Interestingly I can read and edit files when using Nautilus's "Network Servers" dialog, so clearly Gnome VFS is doing something that regular mounting is not.
The samba issues described in Comment #7 and Comment #8 can be fixed by applying the patch from http://lists.samba.org/archive/samba/2006-August/123664.html to the samba version on the server.
Created attachment 136257 [details] server smb.conf
My bad. Attachment sent before comments! I was having problems similar to those mentioned in Comments #7 & 8. Grabbed the upstream patch mentioned in Comment #9, applied it to latest FC5 Samba SRPM (samba-3.0.23a-1.fc5.1), rebuilt the binary RPM and installed it on a newly-upgraded FC5 Samba Server. It immediately fixed the problem on 2 of 3 shares (IT, log_archive) mentioned in the attached smb.conf file. The third, SECURITY, continued to display the same issue. After several config. tweaks and server restarts, I gave up two days ago. This morning I turned up the debug level to max and restarted Samba so I could submit a detailed log for this bug report, but the third share started working! I can submit the detailed log report, if somebody thinks it would be useful.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I can report that this now works with one caveat. Mounting a shared subdirectory works: mount -t cifs -o user=user,domain=Dom //192.168.0.1/subdir /mnt I can create, read, edit, and delete. However, mounting a shared root directory still has the problem: mount -t cifs -o user=user,domain=Dom //192.168.0.1/c$ /mnt I can create and delete, but I cannot edit or read. I assume that this has to do with the special character (c$)? This did work on FC4. Thank you.
I had the following command working fine under FC5 where the mount point had been defined previously: mount -t cifs -o user=xxxx,password=xxxxxxxxx,uid=yyyy,gid=yyyy //rentedfs1.york.ac.uk/phys /mnt/F However in FC6 with kernel 2.6.18-1.2849.fc6 I get: mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) I seem to be unable to get this to mount at all in FC6 Is there a workaround?
there were some recent CIFS fixes in the last update kernel that went out, is that still causing problems? (There are more to come in the one I'm queueing up that should be out in the next week too).
2.6.18-1.2849 still has crazy file permissions like -rwxrwSrwt. This is probably against a stand-alone Windows 2003 Server. BTW, these should definitely be default: mapchars, sfu. BTW, noperm is probably good too; the server is responsible and the UIDs are probably nonsense anyway. BTW, you're getting this info several days late and you're lucky I bothered to email it to myself at a machine where I keep my damn Bugzilla account info. Debian does this right; a simple email to 186628.com should do the job.
> 2.6.18-1.2849 still has crazy file permissions like -rwxrwSrwt. This is intentional (well, except for the sticky bit). The sgid bit set with the group execute bit cleared means that the file is eligible for mandatory locking. The sticky bit is an oversight and is cleared in more recent kernels. It generally doesn't mean anything on files though. > BTW, these should definitely be default: mapchars, sfu. Please open a separate BZ for that if you want to pursue it, though this is really an upstream policy decision. > BTW, noperm is probably good too; the server is responsible > and the UIDs are probably nonsense anyway. Hmmm... noperm Client does not do permission checks. This can expose files on this mount to access by other users on the local client system. ...sounds like a bad idea, but I agree that better UID/GID mapping is a good idea. There's been some discussion recently on how best to do it. ...since none of these have much, if anything, to do with the original problem, I'm going to go ahead and close this case. Comments 6-11 imply that this original problem is fixed. Please reopen this bug if you're still having the original problem mentioned here on recent fedora releases.