OS X file permissions issue

May 20, 2008 3:41 PM

OS X Sites folder permissions and a question about flags on the files in bash. What gives?

I use my MacBook Pro as a test server, running Apache. I sync my files (two-way sync, using Chronosync) between my Mac and my home Windows system. Sometimes after a sync my test site breaks - I don't have permission to access my own files. Sure, a chmod -R 755 * on my Sites folder fixes it, but why is it happening? I don't need to have files at 755 for them to work on my Linux server, so why does the Mac refuse to deliver any CSS or javascript files unless execute permissions are set?

Finally, this one is driving me nuts: What's the extra flag at the end of the file for in Terminal? When I check file permissions with ls -al some files show as -rwxr-xr-x+, others show as -rwxr-xr-x@, and some are -rwxr-xr-x with no + or @ appended. Nothing I've been able to find online explains what the @ or + flags mean, or why they may be appended to some files but not others. I've never seen similar flags on any Linux system I've used. Should I even care?

posted by caution live frogs to Computers & Internet (7 answers total)

Apache runs as a different user and can't see the files in your Sites directory unless the directory is readable which is what the x flag is used for for directories. Generally to read a file that is owned by a different user you need perms for both the file (r) and the directory holding the file (x).

I dunno about the @ signs. Huh.
posted by GuyZero at 3:53 PM on May 20, 2008

Also, why it works on Linux - my guess is that your Apache process there is running as a different user, possibly root, which means that it can read everything regardless of perms.
posted by GuyZero at 3:54 PM on May 20, 2008

If Chronosync is using ftp or sftp (ssh) to synchronize files, you might look into umask settings for Chronosync, or perhaps contact their technical support for help with their adjustment. Once you have the right umask to allow world-readability (files) and world-read and world-execute (directories and scripts), directories and files will have the permissions set to allow web service.
posted by Blazecock Pileon at 3:57 PM on May 20, 2008

Best answer: The manual is your friend. Really.

$ man ls

...

The Long Format
If the -l option is given, the following information is displayed for
each file: file mode, number of links, owner name, group name, number of
bytes in the file, abbreviated month, day-of-month file was last modi
fied, hour file last modified, minute file last modified, and the path
name. In addition, for each directory whose contents are displayed, the
total number of 512-byte blocks used by the files in the directory is
displayed on a line by itself, immediately before the information for the
files in the directory. If the file or directory has extended
attributes, the permissions field printed by the -l option is followed by
a '@' character. Otherwise, if the file or directory has extended security
information, the permissions field printed by the -l option is followed by a '+' character.

As to your problem with Chronosync, sorry, I've never heard of it or used it, so I can't suggest why it doesn't work.
posted by majick at 3:57 PM on May 20, 2008

Best answer: The extended attributes are a new thing. They provide a much finer-grained access control to files and directories. You can see what they are by doing a 'ls -le'. Probably something is getting set in the extended attributes that is causing your problem. You should be able to see in the directory listing what is going on. If you post a follow-up here of what the ls command above give you, maybe we can help, but you can also do a 'man chmod' and read the section titled 'ACL MANIPULATION OPTIONS' to see how to change them.

I am sure they are nice, but so far they have been a pain in the butt for me.
posted by procrastination at 5:17 PM on May 20, 2008

One of the difficulties in mixing unix and windows files systems is the ACL. Unix only knows three types of permissions-ownership, the file-owner, the group-owner, and everyone-else. Windows keeps a full spectrum of permissions for any number of users and groups. If I try to transfer a windows file owned by tom and jane, most unix can't natively support that concept.

And there's another problem...username mapping. At the filesystem level, the computer doesn't store an actual username, it stores a numerical id. If your sync process simply copies that UID, and tom has a different uid on one system than he does on the other, suddenly the files aren't owned by tom anymore. Quite possibly by no one on the destination system. You'll see that in an ls output where one of the columns just has a number instead of a name.

I suspect your problem lies somewhere between the two pits of despair.
posted by nomisxid at 9:52 PM on May 20, 2008

Response by poster: You know, I did try searching the manual pages (web though, not via command line)... but it's difficult to search for "+" or "@" on the web. My fault. Checking the included man pages on my Mac gives me:
"If the file or directory has extended security information, the permissions field printed by the -l option is followed by a '+' character." Nothing about the @ though.

As for -le, that's one I didn't try before. Doing so shows me that all files marked with "+" give me "0: group:everyone deny delete" as extended information. Even more fun, chmod -a and chmod -a# won't remove this permission, as bash reports that the ACL doesn't exist in the first place.

Apparently the Get Info GUI thing in OS X is borked in Leopard; it at some point propagated all ACLs from the default undeletable profile folder (in this case Sites) to all enclosed subfolders. To remove the flags I had to manually move every folder and subfolder, creating a new folder with the same name, moving contents, deleting original, moving new one back. Major pain. Needed to authenticate as root for every delete. Really wish that Leopard had a GUI for the ACLs that actually worked.

Thanks all.
posted by caution live frogs at 9:03 AM on May 21, 2008