mkdir throws Permission Denied error in a directoy even with root ownership and 777 permission
 

I get permission denied error when I try to create a directory. Basically unable to write in a directory.

Though the directory permissions are 777 and root:root.
I am logged as root user.

Background is that this directory(where I am facing problem) with 777 and root ownership was created on a different linux machine. RHEL 6.1 Tikanga and I have copied this directory to RHEL 5.5 and 5.7.


Error got:
[root@<hostname>]# mkdir abc
mkdir: cannot create directory `abc': Permission denied

Any help is much appreciated.

is this a mounted dir or local?

This directory is present on a mounted storage but it is local to that machine. I can write on other parts of the storage but not this directory

so probably you have mounted that dir readonly
can you check it?

This directory is present on a mounted storage but it is local to that machine. I can write on other parts of the storage but not this directory

The problematic directory is not mounted. It is an independent directory just present on a storage.

What is the filesystem for the partition that contains the directory.
Double check the permissions of the directory, or whether it's a symbolic link to another directory.
If the directory is an NFS mount, rootsquash can prevent writing by root.

Check for attributes (lsattr). Check for ACLs (getfacl). Check for selinux restrictions. (ls -Z)

If the filesystem is corrupt, it might be initially mounted RW but when you try to write to a bad area, change to RO.

could not find any sym-links to my directory

output of ls -ltrh
drwxrwxrwx 2 root root 4.0K Aug 31 10:14 <dir-name>

output of df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vdd1 504G 5.8G 473G 2% /mnt/storage

output of fdisk -l
Device Boot Start End Blocks Id System
/dev/vdd1 1 66837 536868171 83 Linux

lsattr <dir-name>
------------- <dir-name>/aaa
-------------<dir-name>/bbb
-------------<dir-name>/cccc
------------- <dir-name>/abxxx
------------- <dir-name>/xyz

Note that aaa,bbb,cccc,abxxx,xyz are the files that were already present in my directory from where I copied.

Now I cant futher create files or directories

getfacl <dir-name>
# file: <dir-name>
# owner: root
# group: root
user::rwx
group::rwx
other::rwx

ls -Z <dir-name>
-rwxr-xr-x root root system_u:object_r:unlabeled_t aaa
-rwxr-xr-x root root system_u:object_r:unlabeled_t bbb
-rwxr-xr-x root root system_u:object_r:unlabeled_t cccc
-rwxr-xr-x root root system_u:object_r:unlabeled_t abxxx
-rwxr-xr-x root root system_u:object_r:unlabeled_t xyz

ls -Z
drwxrwxrwx root root system_u:object_r:unlabeled_t <dir-name>

what is the output of mount ?

/dev/vdd1 on /mnt/storage type ext3 (rw)

disabling SELINUX solves the problem.
echo 0 >/selinux/enforce

But this is not advisable as it is a security threat.
I want to know the root cause and solution other than disabling SELINUX

What kind of device is /dev/vdd?

Part of the problem may be that you are working as root? A regular user may not be restricted by selinux.
Alternately, label the files and directories, but not running as root is recommended anyway. Especially for external storage with global access. An suid file could spell trouble. Consider using nosuid and noexec mount options.

Check your logs on why selinux prevents root from creating a file there. I think it has to do with restrictions on root processes rather than file system permissions. It's been a while since I tried Fedora. Part of the log entry was needed to add a rule allowing a restricted action. Also check for booleans (getsebool -a). Look in /etc/selinux/ for a config listing directories. The installation program uses it to generate policies. Is /mnt/ mentioned?

One update is that the directory for which I am facing problem is created in a RHEL 6.1 machine and has been moved to RHEL 5.7 machine machine. Is there compatibility issue with this? I am facing problem when I move that directory to 5.5 or 5.7 machines and no problems in 6.1 machines.

---------- Post added 09-03-12 at 07:34 AM ----------

No problem when I move it to another machine of 6.1

Changing the file type from unlabeled_t to file_t using the command "chcon -t file_t <diretory-name>" is solving the problem.