OS X file permissions issue

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.

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.

If Chronosync is using ftp or sftp (ssh) to synchronize files, you might look into http://en.wikipedia.org/wiki/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 http://en.wikipedia.org/wiki/File_system_permissions set to allow web service.

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.

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.

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.