How to Cope with File Server Permissions Hell

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.

 By Charlie Schluting
Page 1 of 2
Print Article

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.

Basic Layouts

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 time.

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.)

Hierarchical Troubles

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 possible.

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 control lists.

This article was originally published on Sep 9, 2009
Get the Latest Scoop with Networking Update Newsletter