Bug 186628 - Data from 2003 Server Domain Controller unreadable by FC5 mount.cifs command.
Data from 2003 Server Domain Controller unreadable by FC5 mount.cifs command.
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Layton
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-03-24 15:19 EST by Patrick L. Parks
Modified: 2014-06-18 03:35 EDT (History)
9 users (show)

See Also:
Fixed In Version: kernel-2.6.16-1.2096_FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-21 07:21:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
server smb.conf (14.24 KB, text/plain)
2006-09-14 09:59 EDT, James J. Moore
no flags Details

  None (edit)
Description Patrick L. Parks 2006-03-24 15:19:18 EST
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:

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)
Comment 1 Patrick L. Parks 2006-03-24 15:21:12 EST
This problem does not seem to occur when the 2003 Server is a member server,
only when it's a domain controller.
Comment 2 Matt Goebel 2006-03-31 16:07:20 EST
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.  
Comment 3 Tom Diehl 2006-04-11 09:43:45 EDT
I also have this issue but with fc4.
Comment 4 Tom Diehl 2006-04-11 12:00:32 EDT
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? 
Comment 6 Patrick L. Parks 2006-04-24 21:58:57 EDT
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.
Comment 7 Paul Howarth 2006-08-02 09:32:15 EDT
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).
Comment 8 Grant Ozolins 2006-08-03 05:27:48 EDT
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.
Comment 9 Paul Howarth 2006-08-04 09:52:44 EDT
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.
Comment 10 James J. Moore 2006-09-14 09:59:38 EDT
Created attachment 136257 [details]
server smb.conf
Comment 11 James J. Moore 2006-09-14 10:22:18 EDT
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.
Comment 12 Dave Jones 2006-10-16 16:08:03 EDT
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.
Comment 13 jspot 2006-10-27 11:20:04 EDT
I can report that this now works with one caveat. 

Mounting a shared subdirectory works:
mount -t cifs -o user=user,domain=Dom // /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 //$ /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.
Comment 14 Mike Cohler 2006-11-16 12:58:24 EST
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?
Comment 15 Dave Jones 2006-11-20 18:54:14 EST
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).
Comment 16 Albert Cahalan 2006-11-28 02:30:25 EST
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@bugs.redhat.com should do the job.
Comment 17 Jeff Layton 2008-01-21 07:21:39 EST
> 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
                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.

Note You need to log in before you can comment on or make changes to this bug.