[Samba] OS X Clients Can't Create Sub-Directories

[Andy Liebman]

Kimball Larsen wrote:
> I'm running samba on a local linux server, with a bunch of shares.  Over the last several years, this has worked perfectly in our heterogenous network of OS X and Windows.  All my windows clients still work perfectly - my users can mount the samba shares and create, rename, move etc files and folders. 
>
> However, recently (starting yesterday) my OS X clients are unable to rename any sub directories on any of my shares. 
>
> So, if I have a structure like this: 
>
> Share Root
>     FooFolder
>         Bar Folder
>
> My OS X users are able to create and rename directories in the share root, but are unable to rename folders they create in sub directories.
>
> So, if my OS X user navigates to FooFolder and tries to create a new folder there, a new folder is created called "untitled folder", but I'm unable to rename it.  Every time I do, the finder says "You don't have permission to rename the item "untitled folder".
>
> But, again, I can create and rename folders in the root of the share without issue. 
>
> Here are the relevant bits from my smb.conf (Neighborhood is the name of the share):
>
> [global]
>         log file = /var/log/samba/log.%m
>         load printers = no 
>         guest account = nobody
>         passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .
>         socket options = TCP_NODELAY
>         obey pam restrictions = yes
>         encrypt passwords = true
>         passwd program = /usr/bin/passwd %u
>         passdb backend = tdbsam
>         dns proxy = no
>         delete readonly = yes
>         server string = %h server
>         invalid users = root
>         workgroup = lappygroup
>         security = share
>         syslog = 0
>         panic action = /usr/share/samba/panic-action %d
>         max log size = 1000
>         unix extensions = no
>
>
> [Neighborhood]
>   comment = Who are the people in your neighborhood...
>   path = /mnt/brick/Neighborhood
>   public = yes
>   writable = yes
>   create mask = 0777
>   directory mask = 0777
>   force user = nobody
>   force group = nogroup
>
>
> And here are the permissions on the root of the share:
> root at jake:/mnt/brick# ls -la | grep Neighborhood
> drwxrwxrwx 46 nobody nogroup 2360 2010-02-02 15:31 Neighborhood
>
> And the "Advertising" directory where I want to create a sub directory.
> root at jake:/mnt/brick/Neighborhood# ls -la | grep Advertising
> drwxrwxrwx  4 nobody nogroup       144 2010-02-02 15:49 Advertising
>
> And the resulting "untitled folder" that is created by the OS X client. 
> root at jake:/mnt/brick/Neighborhood/Advertising# ls -la
> total 11
> drwxrwxrwx  4 nobody nogroup  144 2010-02-02 15:49 .
> drwxrwxrwx 46 nobody nogroup 2360 2010-02-02 15:31 ..
> -rwxrwxrwx  1 nobody nogroup 6148 2009-05-04 10:03 .DS_Store
> drwxrwxrwx  3 nobody nogroup 1064 2008-12-17 15:38 Lead Tracking
> drwxrwxrwx  2 nobody nogroup   48 2010-02-02 15:49 untitled folder
>
>
> What should I be checking?
>
> Thanks!
>
> -- Kimball 
>
>
>
>   

Hello Kimball,

What version of Samba Server are you running?

What version of OS X are you running?  There have been huge changes in 
the use (and setting) of extended attributes with Snow Leopard.  These 
can cause all sorts of issues that were not there before.  Have your Mac 
clients just updated to Snow Leopard?

I see that there is a .DS_Store file in the directory.  The permissions 
on those files can prevent User B from accessing a share that User A 
accessed (or at least the directories in that share that were accessed 
by User A).  In a shared environment accessed by multiple OS X servers, 
it's usually best to disable the creation of .DS_Store files on network 
volumes, as the wrong permissions on these files can prevent users from 
doing things they expect to be able to do.

There are many postings on the net about how to disable the creation of 
the .DS_Store files,  for example:

http://www.macosxhints.com/article.php?story=20051130083652119

Regards,
Andy