Description of problem: I create a share folder via samba server on another Linux machine, and mount this share folder on Redhat 5.4. I get a permission denied error when I use "touch" command to create a file in the local mount point folder, but this issue does not happen on Redhat 5.2 nor Redhat 5.3. Version-Release number of selected component (if applicable): $ uname -a Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:54 EDT 2009 i686 i686 i386 GNU/Linux $ lsb_release -a LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: RedHatEnterpriseClient Description: Red Hat Enterprise Linux Client release 5.4 (Tikanga) Release: 5.4 Codename: Tikanga $ rpm -qa | grep samba samba-common-3.0.33-3.14.el5 samba-client-3.0.33-3.14.el5 How reproducible: Steps to Reproduce: 1.Create a share folder on SUSE or Ubuntu: $ mkdir /home/guoyibj/share $ chmod 777 /home/guoyibj/share a. Add a samba user guoyibj # smbpasswd -a guoyibj b. Add the following lines to /etc/samba/smb.conf [share] inherit acls = Yes path = /home/guoyibj/share read only = No create mask = 0777 directory mask = 0777 c. Restart samba server # /etc/init.d/smb restart 2.Mount the share folder on Redhat 5.4: $ mkdir /home/auser1/fs # mount -t cifs //9.123.154.100/share /home/auser1/fs -o uid=auser1,gid=users -o user=guoyibj,password=****** 3.Use touch command to create a file in the local mount point folder: Actual results: Get a permission denied error, but this file has been created. $ cd ~/fs $ touch 1 touch: setting times of `1': Permission denied <---- Problem $ ll total 0 -rw-rw-r-- 1 nyan users 0 Nov 24 20:18 1 Expected results: Should not return the permission denied error because the user has "rw" permissions. Additional info: 1. I tried to use this mount command on Redhat 5.2 and Redhat 5.3, and I could successfully use touch command to create a file without returning an error. 2. I tried to use this mount command on two SUSE10SP2 machines, and this issue did not happen. On one of the SUSE machine, the samba-client version is newer than 3.0.33, and the other one is older than 3.0.33. So I think it is not a bug of samba client. 3. I tried to create a share folder on Windows, and grant complete permissions to user guoyibj, and use this mount command on Redhat 5.4. This issue did not happen.
How reproducible: everytime
Samba client passes everything to the kernel, but it seems that the kernel is not able to deal with the mount user and treat it as another user, but there is no write permission for another user to create file, so I get an permission denied error. I tried the following umask command and could successfully create a new file using touch without errors. $ umask 000 $ cd /home/auser1/fs $ touch newfile
I'm pretty sure this is a known issue and is actually a design flaw... CIFS uses unix extensions to fetch permissions from the server and tries to enforce them on the client. When a new file/directory is created on the server however, it ends up being owned by the user whose credentials are used for the mount, not as the user on the local machine who issued the system call. One workaround is to disable permission checking on the client entirely by mounting with '-o noperm', but that does mean that anyone on the machine will be able to access files on the mount. Unfortunately, this is probably not something we'll be able to fix within the scope of an update release, but we may be able to do something in later RHEL versions (RHEL 6.0 and up).
I think I saw this behaviour mentioned and a bugfix for it when going through kernel changelogs to solve another cifs problem. Some quick googling suggests that this is the same issue: https://bugzilla.kernel.org/show_bug.cgi?id=8437 which was apparently fixed in 2.6.27 and later.
Hum. See also here: http://www.linuxforums.org/forum/linux-networking/161805-cifs-setting-times-file1-operation-not-permitted.html I also recall that this behaviour improves if the user and/or group id on the server machine are identical to the client...
I don't believe those are the same issue... The root cause here is the fact that CIFS tries to enforce permissions on the client but uses a single set of credentials to do all operations to the server. If those credentials on the server don't match the uid of the user doing the operation on the client, then there's (obviously) a problem. The right solution is to fix it so that users use their own credentials when dealing with the server. I'm working on a patchset for that upstream now, but it's unlikely we'll ever be able to take that patch into RHEL5. If you're interested in following its development the latest set is here: http://lists.samba.org/archive/linux-cifs-client/2010-April/005851.html In fact, on that note, I'll go ahead and close this as WONTFIX. If you're being bitten by this in RHEL, your best bet is to probably use noperm and limit who has access to the mount.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Update: Just happen when mount with vers=1.0 get same result on RHEL-6 RHEL-7 RHEL-8