Join 3,415 readers in helping fund MetaFilter (Hide)


Centrally manage FreeNAS permissions?
November 28, 2011 7:18 PM   Subscribe

Is it possible to centrally control permissions on a FreeNAS or other UNIX-like filesystem?

The FreeNAS instructions on permissions indicate that the client OS is involved in setting permissions: "Once a share is available, the client operating system can be used to fine-tune the permissions of the files and directories that are created by the client."

I'd prefer to be able to centrally establish permissions and have new files and folders inherit from their parent folder. Because I don't know any better way, I added some cron jobs that perform recursive chmod commands on the top-level folders once a minute.

Without these jobs in place new files and folders are created with bizarre permissions by the clients (OS X seems particularly troublesome, since it appears local group IDs get sent along with the files sometimes?) resulting in people being unable to collaborate on items across workstations.

Is there a better way to achieve this? In short, I'm trying to get the same kind of thing that you can easily do with Windows Active Directory shares and permissions.
posted by odinsdream to Computers & Internet (14 answers total) 1 user marked this as a favorite
 
I'm unfamiliar with how FreeNAS works. What protocol are the OS X clients using? AFP? SMB/CIFS? NFS? Something special?
posted by sbutler at 8:06 PM on November 28, 2011


AFP for the OS X clients, SMB for the Windows clients, both clients operating on the same underlying data shares.
posted by odinsdream at 8:21 PM on November 28, 2011


Part of the reason AD has better integration is because all clients use the same protocol to access data. AFP has a very different idea of permissions than SMB does. I'd suggest as a first solution try making the OS X clients use SMB also.
posted by sbutler at 8:24 PM on November 28, 2011 [1 favorite]


When I did something along these lines, I used SMB on the OS X clients as sbutler suggested on a painfully bizarre AD / Linux mongrel of an authentication system/file storage network. I still had a couple of cron jobs that did some chmod work on a couple of client shares that would not play well with others, so you're not too far off the path by my experience. Cron makes the world work.
posted by ndfine at 8:38 PM on November 28, 2011


Alright, does anyone have advice on a more formal work-around for the cron approach? If this is a common issue surely someone's come up with a bash script that:

Loops through top-level directories
Takes the permissions, user and group settings for the directory
Applies those permissions recursively to the sub-directories and files

This would at least simplify the process so that I could easily add top-level directories without adding new cron jobs and new commands.

Either that, or surely I'm missing something about how to set up inherited permissions on Unix filesystems?
posted by odinsdream at 6:26 AM on November 29, 2011


Use NFS.

You can (in theory, anyway) set up an Open Directory server that can work with your AD domain for authentication. This will centralize your UID/GID distribution. NFS uses POSIX permissions, and things work mostly as you'd expect. The main problem I have found is that sometimes OSX understands nested groups, and other times it just doesn't, so try to avoid that if you can.

You'll have a bitch of a time getting all your UID/GIDs matched up and fixing the home directory permissions on the client machines. It is doable though.
posted by Pogo_Fuzzybutt at 6:45 AM on November 29, 2011


You can (in theory, anyway) set up an Open Directory server that can work with your AD domain for authentication.

I don't have an AD domain. User authentication was via the FreeNAS box's own users and groups. I need to preserve the ability for both OS X and Windows clients to connect, as well as remote connections via SCP.

Are you saying I need to get the local client UID/GIDs to match the ones on the server?
posted by odinsdream at 6:57 AM on November 29, 2011



Are you saying I need to get the local client UID/GIDs to match the ones on the server?


Yeah, you life will be much easier if you do. A directory server can simplify this, but might be overkill if you have like 4 machines and users.
posted by Pogo_Fuzzybutt at 4:16 PM on November 29, 2011


We're not very large, but I don't want to redirect the entire home directory to NFS, and I still want to offer share access to Windows clients, and via SCP.

I'd just like the username with which you connect to the share, through whatever means, to dictate the user and group that's associated with new files created via that connection. This seems like a simple concept. Surely I'm not alone in wanting this.
posted by odinsdream at 5:48 PM on November 29, 2011


to make files/directories inherit the parent's ownership, you need to enable the sgid (set group id) bit on the parent directories. info here, or check the chmod manpage. depending how client machines access the share you may need to do this directly on the NAS rather than from a connected client.
posted by russm at 1:10 AM on November 30, 2011


russm, thanks - I'll give that a try. I've been setting permissions directly on the NAS via command-line.
posted by odinsdream at 6:00 AM on November 30, 2011


We're not very large, but I don't want to redirect the entire home directory to NFS, and I still want to offer share access to Windows clients, and via SCP.

I'd just like the username with which you connect to the share, through whatever means, to dictate the user and group that's associated with new files created via that connection. This seems like a simple concept. Surely I'm not alone in wanting this.


You can have the home directory on a local partition, you don't need to redirect it.

It's that NFS (in particular) uses the UID/GID for permissions and so to the degree there is correspondence between the UID/GID on the server and on the client, things work better.

You are correct that this should be a solved problem. It is exceedingly frustrating that it is not; you are basically punished for running a heterogeneous network. I'm in the same boat - with a mix of Windows, OSX and linux boxes and 68 TB of data - fixing access issues is what I spend most of my time on.
posted by Pogo_Fuzzybutt at 7:46 AM on November 30, 2011


Part of the problem with FreeNAS (and other free solutions) is that there are two many cooks in the kitchen. Let's look the breakdown:

For Windows
- OS: Microsoft
- Filesystem: Microsoft
- Directory: Microsoft
- SMB: Microsoft

For OS X
- OS: Apple
- Filesystem: Apple
- Directory: Apple
- SMB: Apple (10.7) or Samba with Apple patches (< 10.7)
- AFP: Apple

For Novell*
- OS: Linux with Novell addons
- Filesystem: Novell
- Directory: Novell
- SMB: Novell
- AFP: Novell

For FreeNAS
- OS: FreeBSD
- Filesystem: Sun/Oracle
- Directory: ??? Microsoft, or Apple, or Novell, or OpenLDAP, or...
- SMB: Samba
- AFP: netatalk

I think the OpenSource solutions are a great effort, but it's not hard to see why all sorts of problems occur when you want to mix and match. To their credit though, they're close.

[*] Any Open Enterprise Servers out there?
posted by sbutler at 8:05 AM on December 2, 2011


sbutler, the problem with anything other than FreeNAS, though, is that I can't actually do my work. Incremental backups are shit, vendor lock-in is a nightmare, replication is insanely expensive, etc.,

Literally the only problem with the FreeNAS solution so far is this question, which is more of a mild annoyance in that I have a work-around that seems, to me, to lack elegance. It actually works fine.
posted by odinsdream at 9:54 AM on December 2, 2011


« Older Trying to buy a Lenovo small f...   |  Tell me your best gift ideas f... Newer »
This thread is closed to new comments.