Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So, I had just flat out erased my Time Capsules 2TB drive and began running a sync script I wrote alongside a Time Machine Backup. They both have been running for over a day without a hitch, but out of no where I started seeing problems with my script. First, I was denied access to delete one of the folders on my drive (I had to force remove the folder in the terminal). Next, my script failed as a whole do to the following error:

rsync: ERROR: cannot stat destination "destination folder on Time Capsule": Permission denied (13)

Absolutely no idea why. I went into Volumes via the terminal and notice 2 things. First, I had two instances of my Time Machine's HDD. One named normally and the other with a notated -1 after it (say TimeCapsuleHDD and TimeCapsuleHDD-1). If that wasn't strange enough, the owner for the TimeCapsuleHDD was root:wheel with drwx------ permissions. The owner of TimeCapsuleHDD-1 was MyUserName:staff with drwx------ permissions. I attempted to change the TimeCapsuleHDD permissions (which is where my sync apps are writing to) via chown and chmod 755 without it effecting anything. I also attempted to specify chown MyUserName:staff without success. Does anyone know what the cause of this is? I'm now desperately zeroing out my drive hoping to regain proper possession. I couldn't even sudo cd into it without actually logging in as root. If this does happen again, I would love to learn how to correct it. I did read that this may be do to issues with ACL. The worst part is, I had a permissions issue on my new 2013 iMac the other night in which I had to recover install Mountain Lion to correct the randomly caused issues (I wasn't able to create a new account on my computer as my permissions were denied).

share|improve this question
See also: -- rsync causes my Time Capsule to stop responding until rebooted. The data share becomes inaccessible to all clients (OS X, Windows, Linux) on the network until the reboot. You should monitor an rsync session to determine if/when the TC goes off the rails. It's possible your Mac is not dismounting during the freeze and just creates a second mount after the TC is online again. – jscott Mar 16 '13 at 20:53
up vote 0 down vote accepted

The only answers I can conclude is that either the ACL files were messed up (which in that case they'd need to manually be edited without use of the chmod command and such). This doesn't explain the misnomer in the naming conventions for TimeCapsuleHDD and TimeCapsuleHDD-1. Now, as I could tell before, I did not have access to TimeCapsuleHDD but had full access to TimeCapsuleHDD-1. After wiping the drive and trying everything again, it seems the names swapped. I have no idea what TimeCapsuleHDD-1 is suppose to be used for ( as there is a mount called Time Machine Backups which I would assume would be for the Time Machine) while TimeCapsuleHDD is suppose to be the Network HDD mount in Volumes. Somehow, these mount names were swapped for me (spontaneously mind you because this happened after previous syncs). This may have caused an issue (still wondering why they spontaneously swapped though). I noticed after the wipe that I own TimeCapsuleHDD and root:wheels owns TimeCapsuleHDD-1.

Edit: I now know what causes TimeCapsuleHDD-1 to appear and what caused this permissions error. Seems that OSX does create and hot swap these in the Volumes folder per whichever mount (either the Time Machine BackUp or the actual HDD mount) is accessed first. When Time Machine starts up, it names a temporary mount based off of the HDD's labeled name. If you already have the HDD mounted, it will dub a -1 after it, if not... it will take the normal name. Hence if you mount the HDD after Time Machine starts, you're mount will be labeled with the -1 after it (which is dumb imo). To prevent this, you should mount the HDD on boot. The odd part is, I already did this... but I guess at some point it unmounted and they switched. Here's the reference I found for more info:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.