[SOLVED] Can't "cd/ls/etc" directory even as "root"

kaza · 02-28-2018, 01:00 AM

Hello!

I've encountered a strange problem at work: I wanted
to remove some file under some directory but was unable
to "cd" into it, even after "su -".
Neither could I "ls" in this directory. Doing "\ls -la"
of it's parent directory gives permissions as:

Code:

[root@server_name users]# \ls -l
total 188
.
.
.
drwxrwxrwx  32 root     bin  20480 Feb 28 07:24 user_back

[root@server_name users]# cd user_back
-bash: cd: user_back: Permission denied

[root@server_name users]# \ls -la user_back
ls: user_back: Permission denied

[root@server_name users]# chown -R root:root user_back
chown: changing ownership of `user_back': Operation not permitted
chown: cannot read directory `user_back': Permission denied

[root@server_name users]# uname -a
Linux server_name.site.local 2.6.9-78.ELsmp #1 SMP Wed Jul 9 15:46:26 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

[root@server_name users]# whoami
root
[root@server_name users]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),556(beoper)

Interestingly, it's possible to view the contents of that directory
on widows through "Map network drive".

Originally the directory name was of the form: "user.back",
I managed to rename it but that's all, same access problems
remained. Before I renamed it it had been dated to 2010.
Since then we had more than a few total system shutdowns
I'm pretty sure no process is using this directory currently.

So, what can cause such a strange behavior?

TIA,
kaza.

rtmistler · 02-28-2018, 06:30 AM

All I can see is that the directory is in the bin group, which you appear to be part of as root. Perhaps try changing the group, chgrp to root.

Why in the world do all of your ls calls have a \ in front of them? Alias or something?

You didn't say, I'm sure you're checking, but if you feel there's nothing in there, then I'd also try "rm -rf" for that directory.

rtmistler · 02-28-2018, 06:31 AM

Another option is to live boot off of DVD or USB, mount your drive and then do what you want as root to that file system and directory.

rknichols · 02-28-2018, 09:45 AM

How is that directory mounted? If it's a remote filesystem mounted via NFS, be aware that root privileges do not propagate across NFS unless the filesystem has been exported with the "no_root_squash" option. Without that option, your "root" ID gets translated to "nfsnobody", and that ID lacks permission to access the directory.

Emerson · 02-28-2018, 11:59 AM

Quote:

So, what can cause such a strange behavior?

One possible answer is some Windows virus is encrypting this volume.

kaza · 02-28-2018, 03:39 PM

Thanks for the many replies.

First about the possibility that a Windows virus encrypting the volume:
the directory into which I can't cd is just one of the many existing in
its parent directory and all other directories are OK and any this one
directory shows this strange behavior. I don't think a virus would
be so picky.

As for NFS: yes, the access is through NFS (NAS, rather) so the
"irrelevance" of "root" permissions on the NFS server side might be
a plausible explanation. But what to do if that's the case?
And why only a single directory out of many which are OK?

I absolutely can't remove this directory because some important files might be there
I don't know if backup managed to get into it or it too failed to access it.

And since that's the filesystem on which few people are working, I don't think I can
unmount it, boot from disk or USB and manipulate a single directory.

rknichols · 02-28-2018, 04:20 PM

Quote:

Originally Posted by kaza

As for NFS: yes, the access is through NFS (NAS, rather) so the
"irrelevance" of "root" permissions on the NFS server side might be
a plausible explanation. But what to do if that's the case?
And why only a single directory out of many which are OK?

Looking again, I see that the "rwx" permissions for "other" should have been sufficient for access. Sorry I missed that.

Can you connect to the NAS device's administrative interface (for NAS appliances, commonly done with a web browser)?

If you can see the files from Windows, can you also move or copy them to another directory?

kaza · 03-01-2018, 02:12 AM

Solved!

I managed to cd/ls/etc. in the problematic directory by becoming the user of the directory
from which this "user_back" directory had been created
(had to change his password on the NIS server as root before, since he's no longer works here
it affects nobody). I guess the group "bin" somehow interfered when attempted
access as "root".

Thanks for everyone for the help,
kaza.