Root can't change file permissions...
unixDon
look like:
----rwxrwx 1 nobody nogroup 2.7G ...
I'm logged in as root and I can't change the mode of these files. If I try,
I get:
# chmod 644 fileName
chmod: WARNING: can't change fileName
So far, the only way I have found to recover these files is to copy them
and delete the originals. However, there are hundreds of these and they
are all in the 2-10GB range in size. It will take a LONG time to do this,
even with a script.
Anyone know how to chmod these files? My brain is dead! :-)
Don
Rev. Don Kool
Which UNIX system are you using?
Don
--
*********************** You a bounty hunter?
* Rev. Don McDonald * Man's gotta earn a living.
* Baltimore, MD * Dying ain't much of a living, boy.
*********************** "Outlaw Josey Wales"
Dan Blanco
chown -R root "folder name"
chgrp -R root "folder name"
chmod -R 777 "folder name"
"unixDon" <bkUn...@netscape.net> wrote in message
news:5e226fe6.01120...@posting.google.com...
Steve Woolston
This system you've inherited ... they haven't done something silly with the root
user
have they, like change it's UID?
The behaviour you describe is what I'd expect for a user id whose UID is not 0.
Forgive me if this is obvious and you've already checked, but (a) are you sure
you *are* root (type id to check), and (b) just check they haven't change root's
UID.
Cheers.
Steve Woolston
How about switching to the user that owns the file and trying the chmod? (i.e.
if the user is really "nobody", how about trying "su nobody -c chmod 644
FileName"
This user shouldn't need write permission to the directory these files are in,
because chmod is an inode operation rather than a directory operation. (you need
write permission to the directory to create or delete files, but not to change
file contents or attributes)
I am also wondering if you're running some kind of "secure" Unix that has
special rules.
Cheers
Tintin
Are the files on a NFS mounted filesystem?
Erik Heckers
unixDon wrote:
>
> I just inherited a system and found a large directory with files in it that
> look like:
>
> ----rwxrwx 1 nobody nogroup 2.7G ...
>
> I'm logged in as root and I can't change the mode of these files. If I try,
> I get:
>
> # chmod 644 fileName
> chmod: WARNING: can't change fileName
>
Go to the directory and try a 'df .' or (bdf .)
Is it mounted locally or from a remote machine (NFS, Samba, ...)?
Filesystems from remote machines can restrict access for root
on those directories.
Erik.
Paul Hughett
: I just inherited a system and found a large directory with files in it that
: look like:
: ----rwxrwx 1 nobody nogroup 2.7G ...
: I'm logged in as root and I can't change the mode of these files. If I try,
: I get:
You haven't said which flavor of Un*x.
Linux (and perhaps other flavors) has file "attributes" in addition to
the customary ones, including non-modifiability. The lsattr command
lists the attributes and chattr changes them. If your system supports
such a feature, and these files have been marked as unmodifiable, you
will need to change the attributes (as root) before working on them.
I ran into this problem myself a few years ago, and it took me the
LONGEST time to figure out what the problem was.
Another possible approach might be to tar up the whole mess as root
and restore it as an ordinary user. Remember: "Backups are a method
for reliably violating file permissions at a distance".
Paul Hughett
unixDon
> unixDon wrote:
>
> > I just inherited a system and found a large directory with files in it that
> > look like:
> >
> > ----rwxrwx 1 nobody nogroup 2.7G ...
> >
> > I'm logged in as root and I can't change the mode of these files. If I try,
> > I get:
> >
> > # chmod 644 fileName
> > chmod: WARNING: can't change fileName
> >
> > So far, the only way I have found to recover these files is to copy them
> > and delete the originals. However, there are hundreds of these and they
> > are all in the 2-10GB range in size. It will take a LONG time to do this,
> > even with a script.
> >
> > Anyone know how to chmod these files? My brain is dead! :-)
>
>
>
> Which UNIX system are you using?
>
> Don
Solaris 8 is the machine I'm running on but the files are on an NFS
mounted drive on a Quantum SnapServer (Linux of some sort).
Don
unixDon
I tried that. I get "permisson denied" messages on all the files for
any of the operations you suggested below.
Don
"Dan Blanco" <dbla...@attbi.com> wrote in message news:<2vjP7.466$802.51482@rwcrnsc53>...
unixDon
# id
uid=0(root) gid=1(other)
Everything looks fine.
Don
Steve Woolston <woo...@norwich-union.co.uk> wrote in message news:<3C0DFA38...@norwich-union.co.uk>...
unixDon
However, your followup question did get me thinking... I'm running on
a Solaris 8 box but the files are on an NFS mounted drive that belongs
to a Quantum SnapServer. The SnapServer is running a version of Linux
and I wonder if they have some sort of restrictions...
Don
Steve Woolston <woo...@norwich-union.co.uk> wrote in message news:<3C0DFCFD...@norwich-union.co.uk>...
unixDon
wonder if that system (some Linux variant) has access restrictions
imposed on it... I'll check.
Don
"Tintin" <tin...@snowy.calculus> wrote in message news:<3c0e0...@news.iprimus.com.au>...
Martin Meserve
If this is a NFS mounted file system, your machine needs to have root
access granted by the server that is exporting the file system.
Just because you are root on a machine doesn't mean you have root
access to everything.
--
Martin E. Meserve, K7MEM
I respond to news groups and E-Mail on my own time and therefore
my responses may not be as timely as you, or I, would like them to
be. If I seem to be ignoring you, send me another E-Mail to jog my
memory. Opinions are my own and do not reflect the opinions of my
employer.
Barry Margolin
unixDon <bkUn...@netscape.net> wrote:
>Yes, they are on a Quantum SnapServer that has been NFS mounted. I
>wonder if that system (some Linux variant) has access restrictions
>imposed on it... I'll check.
Most NFS servers map remote superusers to nobody by default. They may
allow superuser access from a restricted list of clients, or you might have
to be logged into the server directly.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
hymie!
bkUn...@netscape.net (unixDon), who said:
>I just inherited a system and found a large directory with files in it that
>look like:
>
> ----rwxrwx 1 nobody nogroup 2.7G ...
>
>I'm logged in as root and I can't change the mode of these files. If I try,
>I get:
>
> # chmod 644 fileName
> chmod: WARNING: can't change fileName
It wasn't until much later that unixDon admitted that these files are
located on another system and are accessed via NFS.
By default, root access does not cross NFS mounts. You would need to get
on the machine that hosts these files, and attempt to change the
permissions from there.
hymie! http://www.smart.net/~hymowitz hy...@lactose.smart.net
===============================================================================
I buy a hammer / I smash someone's head open / Outlaw all hammers
--original haiku
ask me about UCITA and DMCA
===============================================================================
dave...@spamcop.net
> It wasn't until much later that unixDon admitted that these files are
> located on another system and are accessed via NFS.
"admitted" implies that he was intentionally deceiving us, which I
don't think is the case.
> By default, root access does not cross NFS mounts. You would need to get
> on the machine that hosts these files, and attempt to change the
> permissions from there.
Yes, but "permissions" is not as accurate as, say, "export parameters".
Permissions generally means a chmod type of thing in the Unix world,
and that won't help a bit.
Dave Hinz
Stefaan A Eeckels
bkUn...@netscape.net (unixDon) wrote:
> "Rev. Don Kool" <old...@home.com> wrote in message news:<3C0D7A39...@home.com>...
> > unixDon wrote:
> >
> > > I just inherited a system and found a large directory with files in it that
> > > look like:
> > >
> > > ----rwxrwx 1 nobody nogroup 2.7G ...
> > >
> > > I'm logged in as root and I can't change the mode of these files. If I try,
> > > I get:
> > >
> > > # chmod 644 fileName
> > > chmod: WARNING: can't change fileName
> > >
> > > So far, the only way I have found to recover these files is to copy them
> > > and delete the originals. However, there are hundreds of these and they
> > > are all in the 2-10GB range in size. It will take a LONG time to do this,
> > > even with a script.
> > >
> > > Anyone know how to chmod these files? My brain is dead! :-)
> >
> >
> >
> > Which UNIX system are you using?
> Solaris 8 is the machine I'm running on but the files are on an NFS
> mounted drive on a Quantum SnapServer (Linux of some sort).
Aha! You should have said so in your orginal post.
Root has no special privileges on NFS mounted file systems.
You'll have more success logging on as the owner of the
files/directories. Alternatively, use the management interface
on the SnapServer (I've never used one of them, so I hope the
thing will let you do this) and add "no_root_squash" to the
options for the relevant directory in /etc/exports.
--
Stefaan (GPG Fingerprint 25D8 551B 4C0F BF73 3283 21F1 5978 D158 7539 76E4)
--
"Object-oriented programming is an exceptionally bad idea which
could only have originated in California." --Edsger Dijkstra
Jonas Bygdén
bkUnixDon> I tried changing to "nobody" and doing the chmod... Still
bkUnixDon> no go. However, your followup question did get me
bkUnixDon> thinking... I'm running on a Solaris 8 box but the files
bkUnixDon> are on an NFS mounted drive that belongs to a Quantum
bkUnixDon> SnapServer. The SnapServer is running a version of Linux
bkUnixDon> and I wonder if they have some sort of restrictions...
Well, there's your problem then.
You have to delete these files on the NFS-server, if you have to
delete them (they're not using any diskspace on your Solaris host).
/jb
--
Jonas Bygdén - jo...@null.net
Barry Margolin
<dave...@spamcop.net> wrote:
>hymie! <hy...@lactose.smart.net> pressed random keys until the following
>was produced:
>> on the machine that hosts these files, and attempt to change the
>> permissions from there.
>
>Yes, but "permissions" is not as accurate as, say, "export parameters".
>Permissions generally means a chmod type of thing in the Unix world,
>and that won't help a bit.
But chmod is precisely what the OP was trying to do. I think hymie was
saying that he should execute the chmod command on the server, not change
the export parameters to allow the client to do the chmod (there's a reason
why NFS doesn't export with root permission by default).
unixDon
I'm in the process of persuing that avenue. The volume is NFS mounted
from a Quantum SnapServer so I'm investigating the access rights on
that system (it's some variant of Linux).
Don
--------
Erik Heckers <ehec...@users.sourceforge.net> wrote in message news:<3C0E41ED...@users.sourceforge.net>...
ilyas guennoun
how can be possible (if root access don't cross NFS) that he could
remove the file; he said that he copied the file and remove the original
????
Barry Margolin
ilyas guennoun <il...@nospam-please.guennoun.org> wrote:
>just a question :
>how can be possible (if root access don't cross NFS) that he could
>remove the file; he said that he copied the file and remove the original
>????
Removing a file requires write permission to the containing directory. If
the directory is world-writable, anyone can remove the file, even
root-mapped-to-nobody.
Chmod is restricted to the file's owner and root.
The interesting thing is that the file owner is nobody, and this is usually
who root is mapped to. But maybe this NFS server maps root to a different
user (or maybe nobody has different userids on the client and server, since
ls is using the client's passwd file).
>> In our last episode, the evil Dr. Lacto had captured our hero,
>> bkUn...@netscape.net (unixDon), who said:
>>
>>>I just inherited a system and found a large directory with files in it that
>>>look like:
>>>
>>> ----rwxrwx 1 nobody nogroup 2.7G ...
unixDon
The problem is that the directory in question is NFS mounted from a Quantum
SnapServer and root on my Solaris 8 machine does not have root access on
the SnapServer. I have asked the sys admin on the SnapServer to fix this
problem and figure out why all the files appear to be getting created with
this strange permission value.
Don
---------
bkUn...@netscape.net (unixDon) wrote in message news:<5e226fe6.01120...@posting.google.com>...
Stefan Berglund
Please don't top-post as it makes it much harder to follow the
discussion and to followup in a meaningful way.
> Thanks to all those that answered my query...
>
> The problem is that the directory in question is NFS mounted from a Quantum
> SnapServer and root on my Solaris 8 machine does not have root access on
> the SnapServer. I have asked the sys admin on the SnapServer to fix this
> problem and figure out why all the files appear to be getting created with
> this strange permission value.
NFS is not a safe protocol and anyone can make a nfs request that has
the uid set to zero, which means that anyone that can mount the
directory can pose as root. Uid 0 should therefor be mapped to nobody on
the nfs-server unless you have a _very_ good reason to do otherwise,
convenience is not a good enough reason.
The correct way of doing this is to have root access to the machine that
owns the filesystem.
--
/Stefan
sbl+...@dd.chalmers.se
Life - the ultimate practical joke
Rev. Don Kool
> bkUn...@netscape.net (unixDon) wrote:
>>"Rev. Don Kool" <old...@home.com> wrote...
>>>unixDon wrote:
[...snip...]
>>Solaris 8 is the machine I'm running on but the files are on an NFS
>>mounted drive on a Quantum SnapServer (Linux of some sort).
> Aha! You should have said so in your orginal post.
> Root has no special privileges on NFS mounted file systems.
> You'll have more success logging on as the owner of the
> files/directories. Alternatively, use the management interface
> on the SnapServer (I've never used one of them, so I hope the
> thing will let you do this) and add "no_root_squash" to the
> options for the relevant directory in /etc/exports.
As even Steve figured out, the fact that you are on an NFS mounted file
system is the problem. Of course he typically failed to tell you why.
The reason is that "root" on the client isn't the same as "root" on the
server. You can either log in as root on the server (i.e., where the
files will be local) and change the permissions there or you can ask the
systems administrator of the server to export them with the option
"anon=0" (bad) or "root=<hostname>" (where "hostname" is the hostname of
your client). That way "root" on the client will have "root" privileges
for that filesystem on the server. (see "man share_nfs" for details).
Hope this helps,
Rev. Don Kool
> unixDon <bkUn...@netscape.net> wrote:
> : I just inherited a system and found a large directory with files in it that
> : look like:
>
> : ----rwxrwx 1 nobody nogroup 2.7G ...
>
> : I'm logged in as root and I can't change the mode of these files. If I try,
> : I get:
>
> You haven't said which flavor of Un*x.
>
> Linux (and perhaps other flavors)
LINUX isn't a "flavor of Un*x [sic]".
[...remaining off-topic LINUX answer to UNIX system question snipped...]
Happy to have cleared things up for you,
Rev. Don Kool
> Thanks to all those that answered my query...
>
> The problem is that the directory in question is NFS mounted from a Quantum
> SnapServer and root on my Solaris 8 machine does not have root access on
> the SnapServer. I have asked the sys admin on the SnapServer to fix this
> problem and figure out why all the files appear to be getting created with
> this strange permission value.
It probably has to do with the "umask" of whatever process/user is
creating them on the LINTEL box.
Hope this helps,
Stefaan A Eeckels
> Thanks to all those that answered my query...
>
> The problem is that the directory in question is NFS mounted from a Quantum
> SnapServer and root on my Solaris 8 machine does not have root access on
> the SnapServer. I have asked the sys admin on the SnapServer to fix this
> problem and figure out why all the files appear to be getting created with
> this strange permission value.
From a cursory look at the snapserver pages, this thing has an embedded OS
and is not a general purpose machine. It might or might not be based on
Linux, but it sure doesn't seem designed to run applications.
So in all likelihood the problem is caused by the machine that created
those files in the first place. As the Snapserver supports CIFS, Appletalk,
Novell and NFS (probably serving the same volumes through different protocols),
this might be due to a mismatch between NFS user/priviledge mappings and
those for the other protocols.
Paul Hughett
: LINUX isn't a "flavor of Un*x [sic]".
Linux is NOT a flavor of Unix(tm) but it IS a flavor of Un*x.
Happy to have cleared things up for you.
Paul
hymie!
>hymie! <hy...@lactose.smart.net> pressed random keys until the following
>was produced:
>
>> It wasn't until much later that unixDon admitted that these files are
>> located on another system and are accessed via NFS.
>
>"admitted" implies that he was intentionally deceiving us, which I
>don't think is the case.
I'm sorry. I didn't mean to imply that he was intentionally deceiving us,
just the he omitted what turned out to be a pivotal piece of information.
>
>> By default, root access does not cross NFS mounts. You would need to get
>> on the machine that hosts these files, and attempt to change the
>> permissions from there.
>
>Yes, but "permissions" is not as accurate as, say, "export parameters".
>Permissions generally means a chmod type of thing in the Unix world,
>and that won't help a bit.
Actually, that's what unixDon wanted:
>>>>>>I'm logged in as root and I can't change the mode of these files.
>>>>>>If I try, I get:
>>>>>> # chmod 644 fileName
>>>>>> chmod: WARNING: can't change fileName
hymie! http://www.smart.net/~hymowitz hy...@lactose.smart.net
===============================================================================
Don Potter
The snap servers have a really bad NFS rev on it....you may have to do it from the interface
(I believe that it allows you to do that)
Rev. Don Kool
> Rev. Don Kool <old...@home.com> wrote:
> : LINUX isn't a "flavor of Un*x [sic]".
> Linux is NOT a flavor of Unix(tm) but it IS a flavor of Un*x.
LINUX is NOT a flavor of Unix(tm)/UNIX/Unix/Un*x/UNix/.../UnIX/etc...
Misspelling the trademark does not make it go away, my son.