Although I prefer the Samba "force group", "force create mode", and "force directory mode" combination, that approach is effectively obsolete (or at least too much trouble) starting with OS X Lion. Right now, the best solution is to use groups and ACLs.

In System Preferences -> Users & Groups:

1. Create a new group for the users who need write access to the file share. Do not try to reuse the "staff" group, a new group is required to force ACLs to be created in step 4.
2. Add the users to the group.

In System Preferences -> Sharing -> File Sharing:

3. Select the shared folder.
4. Add the group to the share permissions (click the + under the "Users" list) and give it read/write access.

Check the ACLs on the shared directory and its contents using 'ls -le'. You should see something like this:

-rw-r-----+ 1 scott    staff  43667456 Feb 17 21:59 filename
 0: group:xxx inherited allow read,write,execute,append,...

The permissions are inherited; all group members now have r/w access.

Adding both the parameters read only = no as well as writable = yes seems to do the trick.

The whole smb.conf

[global]

security = user
passdb backend = tdbsam
unix charset = utf-8
dos charset = cp932
map to guest = Bad Password

[private-share]
path = /home/pi/music
valid users = @smbgrp
read only = no
writable = yes

On the Mac client, the permissions of the mounted share are not root with group wheel anymore. Instead, the owner now is the logged in Mac user and group staff:

$ ls -l /Volumes/samba-share
drwx------  1 hans  staff  16384  1 Feb 18:05 non-pro

I am able to create folders and files as well as delete and rename folders and files. So finally it works as it should.

Sorry this doesn't help the OP, but I can confirm that

unix extensions = no

worked for me. I have Macs running Snow Leopard connecting to Linux (lenny/sid) server with Samba 3.2.3. I am posting this so people will still try that. Much like others, before I put the unix extensions = no line in, the force create mode was being ignored.

for what it is worth, I couldn't access my samba share, maybe you have forgotten to add you username to the samba password group (for lack of beter description phrase)

this is what I did to get mine to work

smbpasswd -a username

after by using nautilus, shared my drive/folder with right-click, sharing, etc.

create your password, and use your username and passsword (which you just entered) to access your samba drive, you can also map this drive in Windows

hope this could help

Usually the authentication prompt is in relation to the destination for your copy.

Thus, from what you're describing, you should enter your Gentoo login credentials. However, I suspect the owner/write permission are too restrictive on that specific volume. Have you checked owner user/group on the problematic volume vs. the other "problem-free" volumes? Are the read/write permissions the same?

To change the permissions without resorting to Terminal, highlight the folder you want to put the user file in and select Get Info (Cmd+i). At the bottom are the permissions. Make sure that where it says "everyone" that it also says "Read & Write." You may have to click the little gold lock at the bottom of the Get Info pane to adjust this. Once you do this, you will be able to copy your folder over.

The problem here is that terminal is trying to write Unix style permissions to the CIFS share during the copy operation.

When you perform "cp" via terminal the data will transfer but the fchmod command will fail as the "core CIFS protocol does not provide unix ownership information or mode for files and directories".

A few solutions:

• Mount the share via command line and engage the noperm option to ignore permission errors.

  mount_smbfs -o noperm "//DOMAIN;[email protected]/blah" /Volumes/blah
  

• Alternatively you can use rsync to copy files (without the -a flag)

  rsync -rl source destination.
  

Source: https://www.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html

Note: I'm just guessing here, I'm not a samba guru.

Samba/CIFS, at least the way you're using it here, does not reproduce credentials between the server and the client. Because of the force user directive on the server, all operations are performed as the user erpm on the server. However, because both the client and the server are running a unix system, they auto-negociated the CIFS POSIX extensions. This makes unix permissions appear to work up to a point, but only as far as the server permits, and you've run into a case where what the unix permissions claim and what the server allows differ.

You'll notice that all files appear as user ID 501. That's their uid on the server.

When you try to create or remove a file, this requires write permission on the directory. All access are mapped to a single user on the server, so write permission boils down to whether erpm is allowed to write to that directory on the server. The answer is yes.

When you run touch, it creates the file and then changes its modification time. Changing the modification time of a file requires ownership, and this is tested by the generic filesystem code, on the client side.

If you run strace touch test, you'll notice that then open call (which creates the file) succeeds, then the utimes call (or rather on Linux the utimensat system call) fails to set the times.

This is actually a bit weird because utimes should succeed, since touch calls it with a NULL argument (meaning “set the timestamp to the current time”), and this is supposed to be permitted to any caller that may write to the file, and not only to the owner like setting an arbitrary timestamp. I suspect that utimensat is actually doing a permissions-based check, and determining that the permissions say you can't write to that file, even though the filesystem would allow a write operation regardless of the actual permissions.

The main advantage of the CIFS POSIX extensions when the server side is running with the permissions of a non-root user are to carry over the executable bit, and possibly group ownership. It may be less confusing if you map user ownership to a single client-side user with the forceuid mount option.

This work for me

[Shared]
    comment = Folder Shared
    path = /path
    unix extensions = no
    force group = root
    force user = root
    browsable = yes
    writeable = yes
    create mask = 0644
    directory mask = 0755
    force create mode = 0644
    force directory mode = 0755
    hide dot files = no
    guest ok = no
    public = no
    valid users = @users

I'm late to this, but I can't be the person that discovered a solution that worked (for me, at least) without putting it out there, since I've been that guy that screams at the "nvm fixed it" comments with no elaboration ;)

Your very first step is to check your fstab. You need to make sure you have

1. Enabled xattrs support on the filesystem you're sharing from, check your fstab.

2. Enabled ACL in mount options too, while you're there. Something like this, adjust for your environ:

   /dev/disk/by-label/nas1 /mnt/nas1 ext4 defaults,user_xattr,acl,commit=60 0 2
   

   I just went through a couple of hours of troubleshooting why I got permission errors. I had simply forgotten point 2.

The rest of my setup was already OK with much less fuss than I thought:

3. Put this in smb.conf [global] section:

   [global]
   vfs objects = fruit catia streams_xattr acl_xattr
   map acl inherit = yes
   fruit:aapl = yes
   fruit:model = MacSamba
   fruit:metadata = stream
   readdir_attr:aapl_rsize = yes
   readdir_attr:aapl_finder_info = yes
   readdir_attr:aapl_max_access = yes
   

   If you wonder what the settings do, I humbly suggest you $> man smb.conf (not a dig at the OP, I confused the text in their post with another more... ignorant post previously.)

The rest of the file can stay default. Change your workgroup name if you're an old Windows 3.11 guy that cares about syncing that across my LAN.

4. In the share you want to have tag support for, these options work well for me:

   [Pr0n]
     comment = Pr0n
     path = /mnt/nas1/Pr0n
     browseable = no
     guest ok = no
     read only = no
     writable = yes
     valid users = 
   
   [ -- snip -- ]
   
     force directory mode = 0775
     force create mode = 0664
   
     # Fruit config
     fruit:posix_rename = yes
     fruit:veto_appledouble = yes
     fruit:nfs_aces = yes
     fruit:wipe_intentionally_left_blank_rfork = no
     fruit:delete_empty_adfiles = no
   

The directory is owned by my personal user and group, I did not need to fuddle around with net grant SeDiskOperatorStatus or any of that.

One reboot later (might as well, right) everything was automagically good, and tags are both allowed and stick.