Red Hat Bugzilla – Bug 186628
Data from 2003 Server Domain Controller unreadable by FC5 mount.cifs command.
Last modified: 2014-06-18 03:35:09 EDT
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
cat: file1.txt: Permission denied
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
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:
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]
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.
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.
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
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 firstname.lastname@example.org 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.
noperm Client does not do permission checks. This can expose
files on this mount to access by other users on the local
...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.