Centos – Is it safe to remount to enable ACL

The corresponding linux commands are :

• ls : Any line with a + after permissions has ACLs on it ( rwxrwxrwx+ ).
• setfacl : Add / Modify ACLs on the file
• getfacl : Read ACLs on the file

Now, I don't know OSx all that well, but when I read those ACLs I see something different. To me, "group: everyone deny delete" would be a rule that states that members of the "everyone" group are denied the ability to delete files.

On linux, however, there is no such thing as "deny delete". The ability to delete is granted by the ability to write. Therefore, if you want to deny delete you also have to deny write which may not be exactly what you're looking for. Then again, you have to figure that it makes sense ... If I can write to a file, technically there is nothing preventing me from zeroing out the file's contents.

But with such a broad rule that seems to act as a catch all you don't really need ACLs at all. Just set the "other" permissions to r-- ( 0600 ) and users that are neither the owner, nor part of the owning group will be unable to write or execute the file. In your example that would mean anyone that is neither the user cb0 nor part of the group staff.

That being said, if you are interested in more indept information on ACLs and their respective commands, I would suggest you take a moment to carefully read through the POSIX Access Controls document : http://www.suse.de/~agruen/acl/linux-acls/online/

"Best mount options" is like asking for the "best flavor of pizza." Different mount options provide different functionality (obviously!). You should read the mount(8) man page, for a description of all the various mount options, for your file system.

This blog provides several speed-optimizing mount options you might consider, and explains some of the risks of using some of them.

Really, I don't think there's much difference between the mount options you would use for an SSD versus a traditional hard drive--except that there should be much less need to care at all for an SSD, since it's already much faster--especially for random seeks. So things like 'noatime', while they will likely improve performance on an SSD, will probably improve it almost imperceptibly, compared to a physical disk, where writing a single 'atime' record is a lot more expensive, relatively speaking.