So you’ve maybe been in this situation before – you’re at a post facility, and you’re trying to move a file from one location to another on a server, and you’re prompted for a password. Or instead of moving the file, it copies when all you did was try to drag it from one location to another. Or you try to write to the file, but it won’t let you save your work. Sup with that? It’s user permissions, my friend. It’s really fun, you’re going to like it. Maybe you’ve never been in any of these situations and it doesn’t seem relevant right now. But trust me, for an assistant editor, this is a really useful thing to learn, and it will save your butt eventually.
Whom is this article for?
This article is targeted at working edit assistants and assistant editors, just starting out or otherwise. It’s probably not going to be super interesting for editors, and if you’re an aspiring edit assistant, there might be more pressing things to focus on.
Reading User Permissions in Finder
In OS X (and other unix-like operating systems, like Linux), when you create a user, it can create files and then it (the user) “owns” the files. And other users can read files that you give them, but they cannot write to the files. Unless they have explicitly been given access, or are part of a Group that has explicitly been given access.
How does this work? How can we see who owns certain files? You can right click on a file or folder > Get Info > Sharing & Permissions, shows the list of users and groups that have access to this file.
Reading User Permissions in Terminal
But if you wanted to check on the status of lots of files and folders, it’s faster to do it in terminal. So, we can open Terminal, and navigate to the folder we’re interested in. For this article I’m not going to explain how to move around through directories in Terminal, so if you haven’t done it before, you can learn it here from Zed A Shaw (Exercise 1, 2, 3, 6, 8, and 9) or from numerous other sources.
Alright. I’m in a directory. Now I’m going to do
ls -l to list the items in the directory. This is what I get:
codeslug is the owner of these items, and staff the group assigned to them. But I’m really interested in this stuff I’ve highlighted yellow. Those cryptic looking letters on the left refer to the user permissions. It reads from left to right; first it says the user permissions for my owner of the item (which is codeslug), and then it says the permissions for my group (staff), and then it goes over other permissions available to other unspecified users and groups. Let’s split them up so it’s more clear:
The pink highlighted stuff are the owner’s permissions; blue is for my group; yellow is for others.
r = read permissions;
w = write permissions;
x = executable (whether programs can be run, or directories can be accessed).
What’s the d for at the beginning? That means it’s a directory, a folder. All of these items happen to be directories.
For the directory Desktop, codeslug can read, write, and open the folder; but staff cannot, and neither can any other users. Same with Documents, Downloads, and Dropbox.
For the directory Film Stuff, codeslug can read, write and execute, staff can read and execute but not write; and others can read but not write. Same for Hightail and Incompatible Software.
I’m going to go into a new directory. I’ve just made three files in it:
These are the permissions that are applied by default in OS X. codeslug is the owner, because I’ve just made it. And I can read and write to it. I can’t execute it, because execute is only applied by default to directories. For everything else, including programs, it needs to be specifically assigned. And my group, staff, can read it, but they can’t write or execute. And other users can read it, but they can’t write to it either.
Files: Changing User Permissions in Finder
So what if I don’t want others to read or write to slugs.txt? I can change the permissions in Finder. I select the file > Get Info > and I can remove staff from the list, and set everyone to No Access.
codeslug can read and write, but staff can no longer read slugs.txt, and neither can anyone else. Now if I look at it again in Terminal, I get:
And staff actually isn’t the owner group at all anymore; it’s been reassigned to wheel.
Files: Changing User Permissions in Terminal
It’s a little bit clunky to be changing permissions in Finder though, so let’s do it in Terminal. We can do this with the chmod command. Let’s say I want to give everyone permission to read and write snails.txt.
chmod 777 snails.txt
The 777 is called octal notation, and reads from left to right.
7 = read/write/execute;
6 = read/write;
5 = read/execute;
4 = read only;
0 = no permissions granted.
Reading from left to right, a score of 7 is applied to codeslug to give read/write/execute permissions, a score of 7 is applied to staff, and a score of 7 is applied to others. snails.txt now looks like this in terminal:
We can see here, everyone can now read, write and execute snails.txt.
What are some common octal notation settings?
chmod 777 –> gives everyone everything; they can all read/write execute; try to avoid using this, it may have unintended side effects
chmod 755 –> the owner can read/write/execute, and everyone else can read/execute
chmod 700 –> the owner can read/write/execute, no one else can do anything
chmod 666 –> everyone can read/write
chmod 644–> owner can read/write, everyone else is read-only
If there’s some file that you can’t seem to work with correctly, check the user permissions.
Folders/Directories: They’re kinda weird
What if you don’t want to change just one file, or a couple files – you want to change the entire folder (the directory). Well, you can do that, but there’s a couple things you need to know about it. For one, whether you change the directory permissions in Finder or Terminal, it doesn’t change the contents of the directory. You have to explicitly state that.
To change a directory’s permissions and its contents in Finder, I need Get Info > click lock in bottom right to apply changes > add the user or group that you want to give permissions to & give them read/write permissions> settings icon in bottom left > “apply to enclosed items.”
This sets the permissions to all files and subfolders inside, to give everyone read/write. But this “fix” is a one time fix only; it is not a magic folder now that magically gives access to other users when you create new items in them. New files will continue to be readable by other users but not writeable by them.
What if you do want a magic folder that lets all files be writable by anyone? The way that we typically deal with this problem is by using an external drive.
External drives are magic? Well they ignore user permissions anyway
Whether it’s formatted NTFS, ExFat or OS-Journaled, external drives and usb keys alike drop permissions issues. Even if someone tries to enable permissions on a drive, it’s easily bypassed by right clicking on the drive and checking off “ignore ownership on this volume”, and removing any foreign users that may be attempting to lock it. We already have enough problems handing OS-Journaled drives to Windows post production facilities and vice versa; can you imagine the havoc that would be created if all files had the user that created them permanently locking them down? So these drives don’t enforce any permissions whatsoever. The “owner” of the files is the current user that is looking at them. If you look in Terminal on a typical ExFat/OS-Journaled/NTFS drive, you show up as the owner, and if you login as another user, it immediately becomes the new owner. And this is one of the many reasons why Avid and many other NLEs actively encourage the use of external drives. (Avid literally gives a warning popup if you start up the software without an external drive mounted.)
An actual magic folder
Okay, fine. But what if you really still want this magic folder, and it needs to be on your computer’s internal drive, not an external thing. Or you need a magic folder on a server or drive where for whatever reason permissions are enabled. Fine. You can do this, by changing the access control list (ACL). We can do this using good old chmod:
sudo chmod -R +a "user:avidmediacomposer allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" "/Users/Shared"
Enter this command in Terminal while on an admin account. Here’s the breakdown on what this command does:
sudo –> temporarily turn you into a superuser. On your own you won’t have permissions to run this command. But if you put sudo in front of it, then you’re saying to unix, I want to become a superuser, let me do this thing.
chmod –> change mode. Allows us to change user permissions.
+a –> a modifier for chmod. Allows us to add ACLs. The previous permissions we learned about – the 777, 700 stuff – those are called POSIX permissiaons. ACLs are another layer of permissions, that can be a lot more specific. We could see POSIX permissions by typing
ls -l; we can see ACLs by doing
ls -le. And if there any special ACLs, we’ll see them at the bottom, saying what they are and which users or groups they apply to.
user:avidmediacomposer –> gives the user called “avidmediacomposer” (assuming this is the name of your second user) the following list of permissions. You could substitute this with a group of users if you wanted instead, for instance group:editors.
This specifies the ACLs we want to add. They allows reading, writing, searching, adding files and directories, and deleting.
file_inherit,directory_inherit –> more ACL permissions. Future files and directories created inside will have (“inherit”) the same attributes that we are specifying right now.
Now a word about this inheritance. It applies to all new files and directories created inside our magic folder. But what happens if a file is moved in? It might be easiest to understand in a list form:
- Create a new file inside magic folder –> new file inherits the folder’s permissions.
- Move a pre-existing file into the magic folder –> the file keeps its old permissions.
- Copy a pre-existing file into the magic folder –> the file inherits the folder’s permissions.
Wait what? Why does copying inherit, but moving doesn’t? Because as far as OS X is concerned, it’s a brand new file. It creates a new file, and then it copies the contents of the old file into the new one. But it doesn’t copy the permissions, it doesn’t care about that. It applies the same permissions as if you were creating a file from scratch. In this case, this parent directory’s ACL permissions specify that we inherit its permissions. So that’s what our copy does.
-R This stands for recursion. It means to go inside the directory, and change the contents of the directory; and go inside any other directories, and keep going inside all of them and changing all of the permissions. When we check the “Apply to enclosed items” in Finder, to change the contents of the directory as well as the directory itself, we were applying recursion there.
"/Users/Shared" –> the filepath of our directory we are applying these special permissions to.
But wait, in this example, I did it in a Shared folder. Isn’t that what the Shared folder automatically does? Wouldn’t this be the entire point of the Shared folder? Well, no, that’s not really how it works. Yes it’s counterintuitive.
Servers: Also weird
Generally, servers will have their own authentication settings that go over and above permissions set on an OS level. For instance, on an ISIS server, I can cd into it like normal, but the permissions I see in Terminal or Finder are not necessarily reflective of the reality. It might say that I have write access when I don’t. Finder might say something like “Custom Access” or it might say that I have read/write permissions but not give me the ability to change them. I can try to sudo in and change the permissions, but my sudo attempt will be denied. I need to be an admin on the server itself, which as an assistant editor, you may or may not have access to, and if you do, you’ll likely be using a specific client to work with the server directly. So if we wanted to change user permissions on ISIS, then we’re going do it from inside the Management Console, and things are very clearly shown there: which ISIS users have access to which workspaces, and what they can do.
The important thing to take away here, is to be able to recognize this behaviour. If you can’t rename something, or move something, or write to something, it’s likely a user permission issue, and it’s solved by modifying either the permissions themselves or your own access level.
So what did we learn?
- all files and directories have “owners”, which is usually their creator
- generally, files and folders are read/write/executable by the owner, but will often be read-only to other users
- we can view and change user permissions using either Finder or Terminal
- we can bypass these user permissions by using an external drive and Ignoring Permissions
- directories are really annoying, but we can change the directory + its contents in Finder or Terminal
- if we want new files to inherit a directory’s permissions, we can do this by changing the access control list using the chmod command
- one of the reasons why we edit on external drives and editing-specific servers like NEXIS/ISIS/Unity is so that we don’t have to fight all of this user permissions stuff
Chmod & Unix Permissions by linuxcommand.org
Unix for Mac OS X Users by Lynda.com, a fun and informative video tutorial that really goes into how user permissions work. If you’re an assistant editor, it’s really good reading.
POSIX vs ACL permissions settings on stackoverflow.com