Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

I seem to have deleted some files on my media drive, simply by changing the permissions.

The Story

I have many operating systems installed on my computer, and constantly switch between them. I bought a 1TB HD and formatted it as HFS+ (not journaled). It worked well between OSX and all of my linux installations while having much better metadata support than NTFS. I never synced the UIDs for my operating systems so the permissions were always doing funny things. Yesterday I tried to fix the permissions by first changing the UIDs of the other operating systems to match OSX, and then changing the file ownership of all files on the drive to match OSX. About 50% of the files on the drive were originally owned by OSX, the other half were owned by the various linux installations. I started to try and change the file permissions for the folders, and that's when it went south.

The Commands

These commands were run recursively on the one section of the drive.

sudo chflags nouchg
sudo chflags -N
sudo chown myusername
sudo chmod 666
sudo chgrp staff

The Bad

Sometime during the execution of these commands, all of the files belonging to OSX were deleted. If a folder had linux based files it would remain intact but any folder containing exclusively OSX files was erased. If a folder containing linux files also contained a subfolder with only OSX files, the sub folder would remain but is inaccesible and displays a file size of 0 bytes.

Luckily these commands were only run on the videos folder, I also have a music folder with the same issue but I did not execute any of these commands on it. Effectively I have examples of the file permissions for all 3 states - the linux files before and after, and the OSX files before.

OSX File Before

-rw-r--r--@ 1 charliehorse  1000  3634241 15 Nov  2008 /path/to/file         32 

Linux File before:

-rw-r--r--@ 1 charliehorse  1000  5321776 20 Sep  2002 /path/to/file/         32 

Linux File After (Read only): (Different file, but I believe the same permissions originally)

-rw-rw-rw-@ 1 charliehorse staff  366982610 17 Jun  2008 /path/to/file           32 

These files still exist so if there are any other commands to run on them to determine what has happened here, I can do that.


Running ls on one of the "empty" deleted OSX folders yields this:

ls: .: Permission denied
ls: ..: Permission denied
ls: subdirA: Permission denied
ls: subdirB: Permission denied
ls: subdirC: Permission denied
ls: subdirD: Permission denied

I believe my files might still be there, but the permissions are screwed.

share|improve this question
Interesting... question, though. When you say the OSX folders were "erased," how do you know they've actually been erased? If it's a simple permissions issue, I'd think you should be able to get access to those files again by mounting the drive as a non-system drive in another system, under another host OS which you could use to apply permissions and access your files. (Maybe correct the permissions, maybe be easier to just copy them off and copy them back once you have access again). – HopelessN00b Jul 13 '12 at 20:40
I actually managed to recover everything and correctly set the permissions to achieve my original goal. I had to reboot into linux to execute the chmod command however, as it would not work on OSX even when as root. The problem is solved, but I still have no idea how the permissions can get into a state where even root can not change them. – charliehorse55 Jul 13 '12 at 21:03
Might want to post that as an answer to your question so others can benefit from it if they come across your question. As to how permissions can be set so root cannot change them... well, the authority to change "permissions" is defined by an ACL, as are root's "permissions," both of which are controlled at a lower (OS) level than user context. Happens on Windows boxes all the time too (usually when updates or patches set the ACL incorrectly on a temporarily-created folder used in the patch process). – HopelessN00b Jul 13 '12 at 22:35

Well your directory was "empty" because you took away the "execute bit" for the directories through your recursive chmod which you need to be able to list files in a directory.

As to why "root" wouldn't be able to change permissions: I'm guessing you ran the "root" commands through sudo which wouldn't work because your user shell couldn't "see" the directory. Running the commands through a true root shell wouldn't have had the same problems.

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.