root has no access to file

Some files on a customer’s Suse box are now not accesible - not even by root. Other files in the same directory are accesssible. It is an long existing box and has been running fine till this morning. There are no prying fingers and nobody but me has root access:

ls ADSO33*

ls: ADSO33.DAT: Permission denied
ls: ADSO33.KEY: Permission denied

sudo ls ADSO33*

ls: ADSO33.DAT: Permission denied
ls: ADSO33.KEY: Permission denied

chmod 777 ADSO33.DAT

chmod: failed to get attributes of `ADSO33.DAT’: Permission denied

I am baffled - I have NEVER seen that root cannot access a file.

Not sure, it will help. Just give a shot.

chmod -R 777 ADSO33.DAT

Two remarks.

  1. you show a # as prompt in your examples. That means that you are already root. No need to do a sudo.

  2. when doing an ls on a file and getting “permission denied” that means that you have no permission to read the directory that contains the file, it is not about the file itself. Better information for us would have been to show (as root):

ls -d <the-absolute-path-to-the-dir-involved>
ls -l <the-absolute-path-to-the-dir-involved>
ls -l <the-absolute-path-to-the-dir-involved>/<one-of-the-files-involved>

and then cut/paste that **completely **in your post (preferable within CODE tags).

> I am baffled - I have NEVER seen that root cannot access a file.

hmmmm…that ADSO33.DAT looks suspiciously like the convention used by
another popular operating system…

so: the file system in use by the partition in which ADSO33.DAT lives
is what?

that partition is mounted read/write? right? a local (to the user)
partition, or on the net and shared?

or, is this *.DAT in the customer’s /home on a Linux formatted partition?

has it been fsck’ed in living memory? are there errors found now, if
checked? after checking, is there anything i /home/lost+found ?

the permissions of the directory the file is in is what?

has s/he accessed that directory while logged into KDE/Gnome/other
Linux GUI as root?

if *DAT is inside /home on a linux formatted partition–from inside
user’s /home, do this and copy/paste to here:

ls -hal .ICE*


.~.
/V
/( )
natural^^-^^pilot

Henk,
I take ir you actually meant “ls -ld…”. etc.

ls -ld /usr/assist

drwxrwxrwx 17 root users 84216 Jun 27 14:18 /usr/assist

ls -l /usr/assist is a bit much as there are 2000+ files in the directory.

ls -l /usr/assist/ADSO33.DAT

ls: /usr/assist/ADSO33.DAT: Permission denied

natural_pilot,

hmmmm…that ADSO33.DAT looks suspiciously like the convention used by
another popular operating system…
so: the file system in use by the partition in which ADSO33.DAT lives
is what?

The file is a cobol data file and is accompanied by a ADSO33.KEY index. There are close to a thousand of them in this directory, most accessible, but all of a sudden a certain number not. It is a textbased POS system and is running for ten plus years.

that partition is mounted read/write? right? a local (to the user)
partition, or on the net and shared?

The file is in the root filesystem.

or, is this *.DAT in the customer’s /home on a Linux formatted partition?

The filesystem is reiserfs

has it been fsck’ed in living memory? are there errors found now, if
checked? after checking, is there anything i /home/lost+found ?

Since it is in the root I will gave to bring the system down and check - will come back to you on that one.

the permissions of the directory the file is in is what?

777 for now - I have tried a few things and will tighten up again after we fixed this problem.

has s/he accessed that directory while logged into KDE/Gnome/other
Linux GUI as root?

It is a textbased POS system that is accessed via ssh / telnet sessions.

if *DAT is inside /home on a linux formatted partition–from inside
user’s /home, do this and copy/paste to here:

ls -hal .ICE*

The files reside in /usr/assist and there are no ICE* files in the directory.

Guys THANK YOU for taking the time out to help me - it is appreciated ver much.

> It is a textbased POS system and is running for ten plus years.

hmmmmmm…

first, since i don’t know what a “textbased POS” is i’m probably not
qualified to give you any answers…

second, if it has been running 10+ years i now wonder just what
version of SuSE or SUSE or openSUSE or SLES it is running…and, if
it is being updated and having security patches applied…

> The filesystem is reiserfs

there was (within the last six months or so) a kernel update to fix a
problem with reiserfs…i think i’d start by researched that…

and, i guess you are aware that reiserfs has fallen out of favor with
openSUSE (and, i guess Novell, but i’m not certain)…well, i mean
reiserfs was the default install about three (or five?) years
ago…now the default is ext3, again…

and, if the box happens to be running SLES (SUSE Linux Enterprise
Server) i think i’d seek a more competent authority on that over in
the Novell forum:
http://forums.novell.com/novell-product-support-forums/suse-linux-enterprise-server-sles/

>> has it been fsck’ed …
> Since it is in the root I will gave to bring the system down and check
> - will come back to you on that one.

might be good to do that along with the kernel upgrade’s reboot needs…

hmmmmmmmmmm…i just had another thought: individual file permissions
are just another bit of data saved on the disk somewhere…if the
drive is gettin’ flakey it could as easily ‘forget’ the permission of
a file as it could corrupt data–therefore, i think i’d do good backup
and check the health of that/those drives…(and, if forced to replace
them i’d seriously consider changing the file system–i understand
that reiserfs progress has been lagging since Mr. Reiser went to prison)

CAVEAT: i’m not a real guru…i’m not qualified to give advice…if
you do as i muse here, and your machine catches on fire and your house
burns down, do NOT come crying to me for what you did to your
system…always seek competent authority.


.~.
/V
/( )
natural^^-^^pilot

I have thought this over during dinner (and a bit after), but fail to see the light.

IMHO an ls needs only access to the directory, so I fail to see how the meesage about access to the file can be true (apart from it being done by root, etc.)

I suppose that cp the file to another directory is as fruitless (no doubt you tried this already).

Suggestions of natural_pilot about the reiserfs seem at least something to try (getting the latest updates).

Do you have a backup (you should have, of course)? What when you retrieve from there (maybe to a ext3 fs)?

> IMHO an ls needs only access to the directory, so I fail to see how the
> meesage about access to the file can be true (apart from it being done
> by root, etc.)

GOOD point!


.~.
/V
/( )
natural^^-^^pilot

On Sun, 28 Jun 2009 15:26:01 GMT, stefaug
<stefaug@no-mx.forums.opensuse.org> wrote:

>
>Henk,
>I take ir you actually meant “ls -ld…”. etc.
>
># ls -ld /usr/assist
>drwxrwxrwx 17 root users 84216 Jun 27 14:18 /usr/assist
>
>ls -l /usr/assist is a bit much as there are 2000+ files in the
>directory.
>
># ls -l /usr/assist/ADSO33.DAT
>ls: /usr/assist/ADSO33.DAT: Permission denied
>
>natural_pilot,
>
>hmmmm…that ADSO33.DAT looks suspiciously like the convention used by
>another popular operating system…
>so: the file system in use by the partition in which ADSO33.DAT lives
>is what?
>
>The file is a cobol data file and is accompanied by a ADSO33.KEY index.
>There are close to a thousand of them in this directory, most
>accessible, but all of a sudden a certain number not. It is a textbased
>POS system and is running for ten plus years.
>
>that partition is mounted read/write? right? a local (to the user)
>partition, or on the net and shared?
>
>The file is in the root filesystem.
>
>or, is this .DAT in the customer’s /home on a Linux formatted
>partition?
>
>The filesystem is reiserfs
>
>has it been fsck’ed in living memory? are there errors found now, if
>checked? after checking, is there anything i /home/lost+found ?
>
>Since it is in the root I will gave to bring the system down and check
>- will come back to you on that one.
>
>the permissions of the directory the file is in is what?
>
>777 for now - I have tried a few things and will tighten up again after
>we fixed this problem.
>
>has s/he accessed that directory while logged into KDE/Gnome/other
>Linux GUI as root?
>
>It is a textbased POS system that is accessed via ssh / telnet
>sessions.
>
>if DAT is inside /home on a linux formatted partition–from inside
>user’s /home, do this and copy/paste to here:
>
>ls -hal .ICE

>
>The files reside in /usr/assist and there are no ICE
files in the
>directory.
>
>Guys THANK YOU for taking the time out to help me - it is appreciated
>ver much.

You may find this an off the wall question but there is method to my
madness:
Just how many files do you have in the directory where this file
resides?

> Just how many files do you have in the directory where this file
> resides?

answered in earlier post: “There are close to a thousand of them in
this directory”

proceed with your madness, please (is there a max number of files in
any one directory which can be accessed?)


brassy

Since the * generated two arguments, read access to the directory appears to be ok.

Since you say it’s a local filesystem, we can discount NFS issues. The bad news is that the last time I saw this kind of behaviour with reiserfs there was filesystem damage and a fsck was needed. Have a look in /var/log/messages to see if there are any messages about disk read errors.

You may need to take the system down and do a reiserfsck. I also hope you have backups of the files.

On Thu, 02 Jul 2009 06:10:49 GMT, brassy
<brassy@no-mx.forums.opensuse.org> wrote:

>> Just how many files do you have in the directory where this file
>> resides?
>
>answered in earlier post: “There are close to a thousand of them in
>this directory”
>
>proceed with your madness, please (is there a max number of files in
>any one directory which can be accessed?)

I have found that various file systems get crabby or slow at anywhere
from a few hundred files to a few hundred thousand file in any one
directory. It depends a lot on the particular file system. For the
particular file system in question, testing may be a useful approach,
ReiserFS put a “really, really bad taste in my mouth” early on; thus i
no longer use it.