Skip to content

Extended Attributes and ACLs on MacOS X

The last article on this topic covered Linux systems, let's see how things are on MacOS X:

EA - Extended attributes

Extended attributes (arbitrary name/value pairs) are marked with an @ sign on the command line:
$ ls -l .DS_Store 
-rw-------@  1 bob  staff     24580 Aug  7 01:04 .DS_Store

$ xattr -l .DS_Store
00000000  20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00  |        ........|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

$ xattr -p .DS_Store 
20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

$ xattr -d .DS_Store 
With the last command, we removed the extended attribute from the file. But there's more:

ACLs - Access Control Lists

With the EA removed, a plus-sign (+) appears, marking Access Control Lists. They can be shown with ls(1) and changed with chmod(1):
$ ls -l .DS_Store 
-rw-------+ 1 bob  staff  24580 Aug  7 01:04 .DS_Store

$ ls -le .DS_Store 
-rw-------+ 1 bob  staff  24580 Aug  7 01:04 .DS_Store
 0: group:everyone deny delete
Somehow this ACL was set for many (all?) files in my home directory and it was impossible to delete files w/o entering the admin password first. Removing the ACL helped:
$ rm -f .DS_Store
rm: .DS_Store: Permission denied

$ chmod -a "group:everyone deny delete" .DS_Store

$ ls -le .DS_Store
-rw-r--r--- 1 bob  staff  24580 Aug  7 01:04 .DS_Store
Deleting this ACL from all objects in $HOME with chmod -R helped indeed and deleting files is now possible again, w/o being asked for a password.


Wow, Miro needs a lot of memory, for holding ~20k of media files in its database:
$ top -o rsize -U `whoami` -n 5 -l 1 | cut -c-90
755-  Miro            0.0  08:42.11 20  3   232+   1678+  727M+  63M+ 772M+ 780M+ 1641M+ 
592   firefox-bin     0.0  33:52.33 27  1   297+   1785+  316M+ 118M+ 529M+ 500M+ 3673M+
594   thunderbird-bin 0.0  04:09.21 27  1   218+    907+  176M+  87M+ 285M+ 273M+ 2839M+
668   firefox-bin     0.0  17:52.92 43  1   371+   1135+  146M+  92M+ 257M+ 400M+ 3603M+
1342- songbird        0.0  19:59.40 14  1   213+    984+   68M+  56M+ 147M+ 142M+  876M+
Indeed, Songbird, having indexed the very same directory is significantly lighter on memory requirements, at least in this particular case. Unfortunately, both are feeling rather sluggish, guess I'll have to look into mpg321 again :-\

Online backups with CrashPlan

When I came across Evaluating Online Backup Services the other day, I remembered that I looked into that topic too a year ago or so. And I was surprised to see that the finalists were the same one as well. In alphabetical order:
  • Arq - unlimited storage, per-user encryption, their backup client costs $29, but then they're offering the restore client for free. Also, data integrity seems to be one of their key benefits
  • Backblaze - unlimited storage at an incredibly low price, per-user encryption but unfortunately no Linux client.
  • CrashPlan - unlimited storage at an incredibly low price, per-user encryption and a Java client, which is good enough.
  • Jungle Disk - unlimited storage, per-user encryption, Linux client, not sure about their security approach though.
  • SpiderOak - per-user encryption, Linux client, Android client coming soon, but unfortunately no unlimited storage plans.
With unlimited storage and an able backup software and because I already had a trial account from last year, I went with CrashPlan. Since I did not want to backup from my workstation, I went for the headless client installation, but with a few modifications.

On this Ubuntu 10.04 system (ia32), the Java JRE was already installed:
$ dpkg -l | grep java
ii  java-common      0.34                     Base of all Java packages
ii  sun-java6-bin    6.24-1build0.10.04.1     Sun Java(TM) Runtime Environment (JRE) 6
ii  sun-java6-jre    6.24-1build0.10.04.1     Sun Java(TM) Runtime Environment (JRE) 6
Also, we wanted to run CrashPlan as a different user:
# useradd -d /opt/crashplan -m -s /bin/false crashplan
# id crashplan 
uid=1002(crashplan) gid=1002(crashplan) groups=1002(crashplan)

# su -s /bin/bash - crashplan 

$ tar -xzf /tmp/CrashPlan_3.0.3_Linux.tgz 
$ cd CrashPlan-install/
$ ./ 
Would you like to start CrashPlanDesktop? (y/n) [y] n
Now that CrashPlan is installed (notice that we did not start the GUI), we'll fix a few permissions and file ownerships:
cd /opt/crashplan
rm -rf .bash_history CrashPlan-install
chown -R root:root .
chmod 0750 .

mkdir tmp
chown :crashplan . 
chown -R crashplan:crashplan .crashplan
chown -R :crashplan log/ conf/  lang/ tmp/ cache/ manifest/
chmod -R g+rw       log/ conf/  lang/ tmp/ cache/ manifest/
Almost done. A few quirks are still left:
sed 's/TARGETDIR\/\${NAME}\.pid/TARGETDIR\/log\/\${NAME}\.pid/' \
               -i.bak bin/CrashPlanEngine 
sed 's/SRV_JAVA_OPTS=\"/&\/opt\/crashplan\/tmp /' \
               -i.bak bin/run.conf
               -i.bak conf/
The first command makes sure the PID file gets written into log/, which is writable for our CrashPlan user. The second one fixes a java exception we got, because /tmp is mounted with noexec here. Finally, we reduce the loglevel, so our logfiles are not getting spammed with debug information. You might want to postpone this change until things are up & running. With all that in place, we can start the CrashPlan engine:
# su -s /bin/sh -c "/opt/crashplan/bin/CrashPlanEngine start" crashplan
The engine will listen on - that's where our desktop client has to connect to. We'll use the desktop client only to configure and schedule the backups. The actual backup jobs will be run by the engine on the server and we can just close the desktop client at any time. Enjoy! But make sure your restores are working too! :-)

Update: Bonus points for extra leetness: CrashPlan offers to ship your initial backup to them. Incredibly useful for bigger backups!