Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running on Ubuntu Server 12.04. I have a folder called Music and I want the default folder permissions to be 775 and the default file to then be 664.

I set the default permissions on the Music folder to be 775.

I configured ACL to use these default permissions as well:

# file: Music
# owner: kris
# group: kris
# flags: ss-

I also changed the default umask for my user account, kris, to 002 in .profile.

Shouldn't and new file/folder now use those permissions when writing to the Samba share? ACL should work with Samba from what I can gather.

Currently, if I write to that folder using my mac, folders are getting 755 and files 644. I have another app on my mac called GoodSync which which is able to sync a local directory on my mac to a network samba share, but those permissions are even worse. files are being written as 700 using that program.

So it looks like Samba is allowing the host/program to determine the folder/file permissions.

What changes do I need to make to force the permissions I want regardless of what the host tries to write on the server?

share|improve this question

Finally figured this one out.

You need to modify the /etc/samba/smb.conf file. For my Music share, I added the following options:

create mask = 664
force create mode = 664
security mask = 664
force security mode = 664
directory mask = 2775
force directory mode = 2775
directory security mask = 2775
force directory security mode = 2775

I'm not sure which one of those actually fixed the issue, but it is writing the correct permissions now when sharing via Samba. I think it's the "force" command being used since the Mac is likely trying to force it's own permissions on the share (and now Ubuntu is forcing it's own permissions instead of accepting my Mac's). Hopefully that helps someone!

share|improve this answer


Running Ubuntu 14.04, samba Version 4.1.6-Ubuntu. I was previously running Fedora 16/samba3 and everything was OK. With Ubuntu/samba4, I could not get Samba to set group write bit on directories.

smb.conf parameters (for testing) included:

create mask = 700             # The file AND mask  
force create mode = 775       # The file OR mask  
directory mask = 700          # Directory AND mask  
force directory mode = 777    # Directory OR mask  

From Windows 7 client, I could create files with mode=775, but created directories always had mode 755.

The problem is with default "UMASK 022" on my personal login which I use to access the shared directories. Edited /etc/login.defs and changed "UMASK 022" to "UMASK 002". Rebooted, and now directories created from Windows 7 client have mode=775. I do not believe this was the same behavior as my previous setup (Fedora/Samba3).

Interestingly, smb.conf parameter "inherit permissions = yes" kind of worked. This parameter supersedes the previous parameters. With parent directory having mode=2777, created subdirectories had mode=766 (the execute bits weren't set), and files had mode=755 (the group/guest write bits weren't set).

The Samba/UMASK interaction and interdependency should be documented.

share|improve this answer

The following entries worked for me:

force security mode = 664
force directory security mode = 775
share|improve this answer

One simple note. Look for "obey pam restrictions" parameter. By default it is OFF or NO or FALSE, but should it be turned ON explicitly, and the umask takes effect! I lost about a week, trying to figure out why my files created with 744 permissions regadless of force create mode 666 or 777... Problem was in this paramater turned ON, and I can't remember why I did that. Turning it OFF solved the rw-vs-ro problem

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.