I've just tried to use the chmod command to give my ordinary user account access to some files. It worked, but not the way I wanted it too... The files got erased, sort of... First all the directories "turned" into some filetype I've never seen, and when I clicked them, they disapeared. 50 gigs of music and programs, gone

The only thing I did was to follow what my linux manual said
As root in the console, I wrote something like chmod 666 followed by the dir name.
That isn't supposed to fuck up the files huh?
Can someone tell me what happened? How do I set filepermissions without destroying my files?

/Marcus

I would be very suprprised if you delted them - can you post the output of:
ls -la /path/to/dir

mount

fdisk -l

[anv@localhost removable]$ ls -la
totalt 164
drwxrwxrwx 6 root nogroup 32768 maj 27 19:28 ./
drwxr-xr-x 6 root root 4096 maj 27 18:49 ../
drwxrwxrwx 5 root nogroup 32768 maj 24 19:27 DC++/
drwxrwxrwx 4 root nogroup 32768 maj 4 09:55 Program/
drwxrwxrwx 4 root nogroup 32768 maj 6 09:37 Recycled/
drwxrwxrwx 5 root nogroup 32768 maj 27 19:28 .Trash-anv/
[anv@localhost removable]$ cd .
. .. .Trash-anv
[anv@localhost removable]$ cd .Trash-anv/
[anv@localhost .Trash-anv]$ dir
Abstract\ 04.zip Byakhee30 Joy\ Behrman.zip pm.zip Win\ Dragon.zip
AquaFish.zip Catarata.zip Macpack-1.zip Rawr\ the\ dragon.zip xp001.zip
Biohazard\ Titanium.zip docs Marcus.dat riders.zip
blue\ dragon.zip Dragon\ Windows\ XP.zip Optics.zip Saker
blue.zip electric4pack+matrix\ bonus.zip ph34r\ m3.zip Thumbs.db
[anv@localhost .Trash-anv]$

Saker is the dir I used chmod on.

What should I do?

---

Ok, now I've moved the files from .Trash, but I still can't get to them in nautilus. Mandrake doesn't register them as libraries but as something else. When I click them they disapear from the view. Is it me, or is this straaange?

I'm having the exact same problem (and it has happened a couple times before) with Ubuntu 7.04 and ReiserFS. It has only happened while setting the permissions of directories (as opposed to single files).

Honestly, this should have been fixed by now. It's been 3 years since this was first posted.

this is why you always backup your data

I had a backup from about 2 hours ago. I already remade everything that had been deleted. That's not the problem.

Chmod should NOT be deleting files. I want to know why it is.

By the way, the exact command I did was:

Are you trying to set permissions on directories in a mswindows partition?

I doubt that person will respond. It's a 3 year old post.

For me, I was setting permissions on a ReiserFS partition.

Permissions on a directory require the executable-bit be set. Thus a setting of 755, 775, or 777 would have been the appropriate choice; not the mark of the devil (666) which is read-write for owner, group, and world.

thats quite ironic

That's pretty odd. Is there any particular reason directories need to be executable?

Also, when I ran `chmod 755` on a directory which I had earlier run `chmod 644` on, all the directories and files reappeared. To me, this really doesn't seem like reasonable behavior.

I didn't design Unix/Linux, so I myself do not understand the rationale either. All I know is that to traverse into a directory, it's permission must have that execute-bit set.

Earlier someone (perhaps you) wanted to change all of the permissions of the files within a directory to 644. In the future, be careful because you may also inadvertently change the permissions on a file that is meant to be executable (e.g. a script, an ELF executable, etc). These particular files also require the execute-bit set (well, not true for every script file).

Anyhow, if you are confident in what you are doing, either of these commands will work for you:

$ chmod -R 644 somedir/*

or:

$ find somedir -type f -exec chmod 644 {} \;

The second command (the 'find') is better in cases where the directory you are chmod-ing contains subdirectories.

The execute bit means something else for directories than for files. It is "overloaded". A bit was needed to allow or deny access to directories, and they happened to pick the 'x' bit since running directories wouldn't make sense.

That's rather annoying. One of my friends described it to me as an "enter" bit for directories rather than "executable", since it allows entry into the directory if set.

This behavior should probably be documented better. After a grep of the chmod man page, I did find information on this, but it certainly isn't noticeable under a casual read.

Perhaps so, but just accept it as a requisite. When you drive a car and want to pull-out onto a major roadway with an oncoming car signaling that it is going to make a turn (either left or right), do you just pull-on out, or do you wait for that car to actually make the turn? The correct choice is to wait for the other car to actually make the turn... but you won't find that documented anywhere either.