What do you do when your Samba users are seeing "permission denied" more often than they see their files? For starters, go back to the drawing board ... literally. Next, get back to the basics with Unix and Linux file permissions.
Running a Samba server or NAS appliance consolidates file storage beautifully for centralized backup and
management, but one thing has never been easy: file permissions. In this article, we
examine why this is often so difficult, and offer some tips on how to ease the pain.
Your new Samba server is humming along nicely, until one day Susan saves a file in
the HR Staff directory that Bob wishes to edit. Bob gets a "permission denied" message.
This is the most common issue, but the problems only get worse when the security
structure requires a complex hierarchical-but-with-a-few-exceptions layout.
Your shared folder structure, or share layout, is extremely important. It is
seriously confusing for users when things change, or when bits and pieces are scattered
all over between shares due to security requirements. Firstly, we recommend diagramming
the directory structure, getting input from as many users as possible. This is
easier said than done, since most shares generally move around but never change name.
Still, if you have the luxury to completely change everything, do it right the first
Initially, you will create groups for user accounts roughly corresponding to the
shares created. Say everyone in HR needs access to the HR share, or everyone in sales
needs access to the sales share. It's easy at this point, assuming that everything
stored in these shares is really for the whole group.
Most importantly, to deal with the Bob and Susan dilemma above, ensure the "create
mask = 2775" (or similar) option is set on every share. Setting 2775 means: the setgid
bit is set (2) which makes newly created directories have the same group ownership as
the parent; owners and group members of the files have full access to them (77); and
that everyone else can enter the directories and view the file names (5), which may or
may not be desirable. (Need to brush up on Linux and Unix permissions? Get back
to the basics with Unix permissions.)
It is easy to give everyone in a group access to a directory, but to allow one new
person access to just part of that, is troublesome. The very last thing you want to do
is to move the affected directory out of the share. Sure, you can create a new group
containing the old one plus the new person for access to the new share, but then people
have to remember where this special case lives. It goes something like this: "oh the
payroll files all live in the Finance share, but Marvin needed access to the July
folder, so that moved out. Go find it in the other share..." As you can see, this
quickly gets insane if those types of things are allowed to happen. IT should be able to
find a workable solution, enabling the business side to function as smoothly a
One way to allow piecemeal access to specific files or directories, is with extended
ACLs. You can specify, for example, that Marvin gets access to a particular
file, in addition to the normal user/group combination that exists on it. See the
getfacl and setfacl manual pages for information on how to configure extended access
This article was originally published on Wednesday Sep 9th 2009
Alternatively, Marvin could also just be made owner of the file, which also has group-writable permissions. This works well, if the default permissions allow all users to enter directories and list the files. Marvin could easily navigate to the right file, and everything would work. If, however, security measures dictate that users outside the group cannot view the contents of the directories, you have two options. Marvin needs to be given execute and read access on all directories leading to the special file, using extended ACLs. The read access is optional, but without it Marvin won't be able to click through to the right location because he wouldn't see the directory; he would need to use the whole, direct path. Likewise, you could just always set the world executable bit on directories (using the create mask of 2771), and any non-group user would be able to access files within a secure that they have access to, via the full path.
See, it can get horribly complex. Some times the answer is to not store "secure"
files on a centralized share at all, if nobody else needs access to them. Other times,
a completely new share may be in order if it logically makes sense and wouldn't create
two places for people to look when trying to remember where something was supposed to
Always the Solution: More Groups
Strange as it may sound, often the best solution is to create a new group. Want a
directory in the Sales share that only Bob and Susan have access to? Create it, and set
the group to the new Bob&Susan group. You don't need to mess with ACLs or new
shares, and groups are managed centrally via LDAP or a text file, so it's easy to see
and manage. Adding a new group works in many other examples, and in fact, we cannot
think of one where a new wouldn't work.
Not Just Windows Users?
If you have Linux users, your problems just got worse. Often NFS access is allowed to the same files that Samba is also hosting. When this happens, your happy Linux users
over NFS generally screw up the permissions. Using Samba, as a Windows or OS X user
would, means that the "create mask" rule is enforced on every file write. Users
accessing files over NFS must pay attention to their umask, and often it is set
incorrectly for group usage.
Setting a umask of 022 means that all files are created as 755, which takes write
access away from group members. NFS-based users must set their umask to 002 when
accessing group shares, or they must manually chmod every file they create. Also, if
each user's primary group is their own private group, in the Linux world, a umask of 002
is not a risk, as home directory files would be group writable, but only to the user
that created them.
This subject quickly gets complex, but often the best way to manage is to design a
layout that makes intuitive sense for everyone. Then, for exceptions, just create a new
group instead of a whole new share; LDAP or Active Directory won't mind large numbers of