MacOS – How to make an Ubuntu Samba Share **completely** writeable from Mavericks

Since you haven't used ls -le as recommended, we don't know what the access control list looks like, but there might be something going on there that is preventing you from being able to write the files. The fact that a newly created user CAN edit the files makes me even more suspicious.

This command will remove ALL access control list entries from the folder and all its subfolders and files:

sudo chmod -RN path/to/folder/containing/files

Once you've cleared the access control list, try resetting the ownership like so:

sudo chown -R ulrikdamn:staff path/to/folder/containing/files

Now grant permissions like so:

sudo chmod -R u+rwX,g+rX,o+rX path/to/folder/containing/files

This gives you full read/write permissions. The "staff" group and all other users get full read permissions. Using an uppercase X, sets the execute bit for all directories within the tree, but leaves the execute bit for regular files as is.

Lowercase x would set the execute bit for all folders AND files. The execute bit must be set for a directory in order to read its contents. If you'd like to give write permissions to the group or others, switch out for g+rwX or o+rwX as necessary in the last command.

Here I'm passing in a folder path. If you want to pass in a single file, just remove the -R from each command. The R makes the command recursive, applying it to an entire directory tree. Without it, the command will modify the permissions for a single file or folder passed in.

In your configuration, you have unix extensions = no which is fine, but that is why symbolic links on the server are showing up as folders and not aliases. In this mode the server resolves the symbolic links and the client never sees them. If the client tries to create a symbolic link, the server actually generates an alias file, not a host-OS symbolic link. Reasons for this include security (preventing someone from getting access to /etc/passwd on the server by creating a symbolic link to it) and client compatibility, as OS X and Windows and Unix have slightly different ideas about what constitutes a symbolic link but they pretty much agree on what is a directory or a file.

Permissions issues with SAMBA are complex, so it's not clear that you do not have a permissions issue. Likewise symbolic like resolving is complex, so it is not clear that what you are doing should, in theory work, and there's always the possibility of a bug (most likely in the SAMBA server).

When accessing a SAMBA server from a Mac, these identities and permissions are involved:

• The Mac User you are logged into the Mac as
• The SAMBA user you are logged into the SAMBA server as
• The SMABA server host OS user you get converted to
• Unix-style file permissions
• For NTFS and HFS+, associated file-system ACLs

So even though you have provided a lot of information, it's still not clear that you are not having permissions problems. The fact that you can mv and cp on the server (using what account?) does not mean you do not have a permissions problem preventing you from doing it on the client (using what accounts and with what effective account on the server?).

If the server is supporting ACLs and since you have options like inherit permissions = yes and inherit acls = yes set there could be some kind of ACL problem that is only allowing read access to directories accessed via symbolic links. There are several other avenues of investigation based on the server configuration.

I would really expect you should be able to find more information in the SAMBA server logs than you have communicated. They should give you a much better sense of exactly what is being denied.

For what it is worth, I tried to duplicate your setup using an Ubuntu 12.04 host as the SAMBA server and could not reproduce your problem. Symbolic links worked for me as expected.