Failure to set permissions on Samba share via CIFS

Bug #496840 reported by Wil Clouser
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

Binary package hint: samba

I'm trying to use a samba share via CIFS and am encountering problems when trying to copy or move files onto the share. If I create a file directly on the share it works as expected (using my umask for permissions) but copying or moving result in errors. To reproduce:

root@boris:/mnt# mount -t cifs //arctic/holding /mnt/testo -o credentials=/root/arctic.cifs.key,domain=Island,iocharset=utf8
root@boris:/mnt# mkdir ~/z
root@boris:/mnt# mv ~/z testo/
mv: failed to preserve ownership for `testo/z': Permission denied
mv: preserving permissions for `testo/z': Permission denied
root@boris:/mnt# ls -ld testo/z
drwx--S--- 2 clouserw root 0 2009-12-14 21:38 testo/z
root@boris:/mnt# umask
0022

This looks _a lot_ like (and might be a duplicate/dependent on) debian bug 532153 ("cifs reports EACCES instead of EOPNOTSUPP for acls" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532153). It looks like that bug is still open though and I'm not sure what the progress is or if there is a workaround in the mean time.

Neither my server or client have ACLs on their filesystem. One maybe relevent note is that mounting the same share from OS X and moving files onto it works as expected with permissions being preserved. OS X has a concept of ACLs on by default.

I'm attaching an strace.

ProblemType: Bug
Architecture: i386
Date: Mon Dec 14 21:44:52 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: smbfs 2:3.4.0-3ubuntu5.1
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: samba
Uname: Linux 2.6.31-14-generic i686

Revision history for this message
Wil Clouser (clouserw) wrote :
Chuck Short (zulcss)
affects: samba (Ubuntu) → linux (Ubuntu)
Andy Whitcroft (apw)
tags: added: karmic
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Andy Bovett (abovett) wrote :

I believe I'm getting the same bug. It only occurs when unix extensions are enabled on the Samba server and client. Server is Debian Lenny. client is Ubuntu Karmic. Some examples:

This works OK:

$ touch x
$ cp x /mnt/SOL/general/

This gives an error:

$ touch x
$ mv x /mnt/SOL/general/
mv: preserving permissions for `/mnt/SOL/general/x': Permission denied

And sure enough the move works but the permissions are different:

$ ls -l x
-rw-rw-r-- 1 andrew andrew 0 2010-01-30 00:17 x
$ ls -l /mnt/SOL/general/x
-rwx-w---- 1 andrew andrew 0 2010-01-30 00:17 /mnt/SOL/general/x*

However this works:

$ chmod 664 /mnt/SOL/general/x
$ ls -l /mnt/SOL/general/x
-rw-rw-r-- 1 andrew andrew 0 2010-01-30 00:17 /mnt/SOL/general/x

This also gives an error:

$ touch x
$ cp -p x /mnt/SOL/general/
cp: preserving permissions for `/mnt/SOL/general/x': Permission denied

Here's my server smb.conf (cleaned up with comments and printer definitions removed)

[global]
   workgroup = ajblan
   server string = %h server
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = user
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   load printers = yes
   printing = cups
   printcap name = cups
[general]
    comment = General files
    path = /media/data/general
    valid users = @fullaccess
    force group = fullaccess
    create mask = 0770
    directory mask = 0771
    writable = yes

And here's my mount line from fstab on the client:

//SOL/general /mnt/SOL/general cifs credentials=/root/.smbcredentials,uid=andrew,gid=andrew,file_mode=0777,dir_mode=0777 0 0

(I'm aware that file_mode and dir_mode don't apply when unix extensions are enabled but I have them there for when they are not.)

This bug is causing me a lot of hassle so if any help/workarounds can be suggested I'd be grateful.

Andy

Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Wil Clouser (clouserw) wrote :

Not super excited about bugs getting auto closed with no way to reopen and no way to easily clone them. I copied and pasted the original report to bug 816663, but all the attachments and discussion remains here.

CC yourself there to continue this game I guess.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.