NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/ultrix/9030

Internet Message Format | 1992-12-22 | 3.8 KB

From: [e-mail]
Date: 21 Dec 92 13:35 CST
Newsgroups: comp.unix.ultrix
Subject: Re: Orphaned Response
Message-ID: <[e-mail]>
Path: sparky!uunet!paladin.american.edu!darwin.sura.net!convex!news.oc.com!utacfd.uta.edu!trsvax!trsvax!tisdec.tis.tandy.com!chris
Nf-ID: #R:ennews.eas.asu.edu:10974:tisdec.tis.tandy.com:28400009:000:3397
Nf-From: tisdec.tis.tandy.com!chris    Dec 21 13:35:00 1992
References: <[e-mail]>
Lines: 73


/* Written  3:43 pm  Dec 16, 1992 by [e-mail] in tisdec.tis.tandy.com:comp.unix.ultrix */
/* ---------- "Re: ultrix 4.2: chgrp/chown problem" ---------- */
In article <[e-mail]>, [e-mail] writes:
|> system: ultrix 4.2A. server is a ds5000/240, clients are ds5000/20.
|>
|> we've discovered what appears to be an anomaly with the use of chgrp
|> and/or chown to change the group on a file. this appears to work fine on
|> a locally-attached disk, but not an NFS client. an example will show
|> what i mean:
[stuff deleted]
|> now try the exact same thing on an NFS client:
|>
|> elrod> ls -alg junk.txt
|> -rwx------  1 rick     staff         388 Oct 29 16:05 junk.txt*
|> elrod> /etc/chown rick.system junk.txt
|> chown: can't change ownership of junk.txt: Not owner
|>
|> which isn't true, BUT:
|>
|> elrod> ls -alg junk.txt
|> -rwx------  1 rick     system        388 Oct 29 16:05 junk.txt*
|>
|>   it changes it anyway. but if i wait for a minute or two, it puts it
|> back the way it was, with no intervention from me:
|>
|> elrod> ls -alg junk.txt
|> -rwx------  1 rick     staff         388 Oct 29 16:05 junk.txt*
|>
|>
|> is this something known? is there an easy fix?

Isn't this due to the two userid's being different on the two machines - and I
don't mean the login names but the numerical id's.  Since then the user rick
is not the same user on both machines, the local one and the host that has the
NFS disk physically mounted.  Or am I missing the point?

--
-------------------------------------------------------------------------------
Paul A. Scowen                INTERNET: [e-mail]
Department of Physics & Astronomy          [e-mail]
Arizona State University        Tel:      [phone]
Tempe, AZ 85287-1504            FAX:      [phone]
-------------------------------------------------------------------------------
/* End of text from tisdec.tis.tandy.com:comp.unix.ultrix */

Yes you are missing a minor point about BSD based systems.  Chown(8)'s behavior
has it's history tied in with quot(8), assuch chown(8) can only be run by root.
This prevented users from changing a file ownership to get around disk quota
restrictions.

Also, if you have not specified root on the client system to be root on the
server system (ie: -r=0 on the FS line in /etc/exports), ROOT cannot do squat
on NFS mounted filesystems, or that the export is writable (ie: no -r on the
FS line in /etc/exports).

The reason it looked like it took place is because it was NFS mounted.  The
command was succesfully processed on you local system, and the failure occured
on the remote system, so the local image was updated for the change, and then
re-updated from the server.  Mystery solved.

These are just a few possibilities, since I have not seen anything about whom
you were doing the chown(8) command as, what your /etc/exports file looks
like, or how the filesystem was mounted (although I suspect it was NOT
readonly).

/* These are only my personal observations and experiences, not my employeer's */
==========================================================================
Chris Riney                     Domain: [e-mail]
Tandy Information Services        UUCP: ...!trsvax!tisdec!chris
Tandy Technology Sqr, Suite 200
Fort Worth, TX 76102             Phone: [phone]; 8:00am-5:00pm CST,Mo-Fr