a directory that root cannot traverse

[Scott Sabo]

I have a user account that created a directory in his home directory. He assigned the permissions 700, and the group ownership is username:usergroup.

Root cannot get into this folder. Not when su root'd, not from native login as root, etc. I cannot chmod, chown, cd to it, etc.

If I try to CD to it, I get "Permission denied".

What the heck is going on?

Thanks,

Scott

[Suraj Singh_1]

Login as root, and su to that user.

Then try changing the permission/ownership etc.

REgards,
Suraj

[Stephen Keane]

Can you ll its parent directory?

Are the user's home directories NFS mounted, or local?

[Scott Sabo]

I can ll the parent directory.

These are all local files, although we also use Samba.

[Geoff Wild]

Do you use NIS?

With NIS - root may not have access - IE - if it is an automunt somewhere else...

Rgds...Geoff

[Stephen Keane]

Can you post the result of

ls -ial

of the parent directory (you can grep for the particular directory if you are worried about security etc)

[Scott Sabo]

181245 drwxr-xr-x 6 smiths CAEUsers 1024 May 20 10:53 FIRE

Note: I had su as the user and changed the permssions so that we could get to the files.

[Sandman!]

Scott,

could you post the output of the bdf command on that directory.
cd to the dir and run bdf there as follows...

# cd

# bdf .

this will tell you if the directory is an nfs mount point and explain why root is having permissions problems.

[TwoProc]

Scott, unless the directory is fried (that is, the file that makes up the definition of this directory has junk in it) - the only way I know that this problem can exist is if it is an NFS mount point. Unless (and this is far reach), you have access control lists (acl) in place? I've not used that product yet, but it's the only other thing I can think of. Maybe someone else could comment on whether or not acl could cause this.

[Scott Sabo]

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 204800 183144 21552 89% /
/dev/vg00/lvol1 311296 113152 196640 37% /stand
/dev/vg00/lvol8 4710400 1400552 3284288 30% /var
/dev/vg00/lvol7 3760128 2449496 1301608 65% /usr
/dev/vg00/lvol4 204800 9136 194520 4% /tmp
/dev/data/new_data 39936000 3098753 34534978 8% /scratch_file
/dev/vg00/lvol6 3637248 2431080 1196808 67% /opt
/dev/vg00/lvol5 24576 14896 9680 61% /home
/dev/new_apps/new_apps
51200000 27253863 22456802 55% /fapps
ice:/iapps/idata/slangm
61440000 32794008 26898416 55% /fapps/fdata/slangm
ice:/iapps/idata/robbs
61440000 32794008 26898416 55% /fapps/fdata/robbs
ice:/iapps/idata/scottec1
61440000 32794008 26898416 55% /fapps/fdata/scottec1
ice:/iapps/idata/smiths
61440000 32794008 26898416 55% /fapps/fdata/smiths
ice:/iapps/idata/loveg
61440000 32794008 26898416 55% /fapps/fdata/loveg
ice:/iapps/idata/connet
61440000 32794008 26898416 55% /fapps/fdata/connet
ice:/iapps/idata/brakovd
61440000 32794008 26898416 55% /fapps/fdata/brakovd
air:/scratch_file 104857600 59677432 42360456 58% /air_scratch_file

[Kent Ostby]

Scott --

That's certainly not the "normal" type of issue.

If this was NFS mounted then it would make sense because you might not have root on the far file system.

What is the full path to the directory ?

Can you traverse it and check permissions / nfs mounts ... or automounts ?

[Global Unix Team]

Hi,
The home directory is very likely a NFS mounted filesystem or a link to a NFS filesystem.
Unless you export your directory on you ICE server with a root=client_name option or anon=0 (dangerous) root has no access to a NFS mounted filesystem.

[Gopi Sekar]

Another possibility could be Access Control List, using which access to a particular directory/file can be denied even for root user.

please check whether you have ACL installed on the system. also check the lsattr for those files and see whether any special flag is set on.

Regards,
Gopi

[Senthil Kumar .A_1]

Hi Scott,

Assuming that , the FS supports ACL. Could you get us the following output...

getacl

regards.

Lets hope.. the attributes can be read..even if ACL is set on the DIR.

[Senthil Kumar .A_1]

Hi scott ignore my previous request..

When i was going through man page of "aclv", i happened to come accross this statement in the warning section...

"ACLs cannot be used to restrict the superuser's access."

Well this should be a strong indicator, that this issue might not be caused by ACL's.

The other possible causes to ponder are ,as others have suggested NIS,NFS..

one that i have come across that could deny access to root is.. "CA's Autosecure" product, which adds a advanced level of security to the basic unix system, and i think....you would be aware of it by now if your were using this for your infrastructure.

Regards.

[Scott Sabo]

(sorry, I was on vacation)

ok, here's the results of the "getacl" on this directory: acl failed for file "/fapps/fdata/smithm", Operation not supported

now, it works to the point of /fapps/fdata/ , but anywhere past there, it does not work, even for other directories past /fapps/fdata