SUMMARY: strange NFS rejections on per-user basis

From: Mark Francillon (markf@marlboro.edu)
Date: Fri Apr 18 1997 - 15:33:30 CDT


I asked why, using some Mac and PC NFS clients and trying to
mount file systems from a SS20 running Sol 2.4, I invariably get
authentication failures when using either of two accounts on the
Sparcstation (but all others work fine).

The answer (thanks Ray Brownrigg) appears to be that authentication
will always fail with UIDs <= 100.

It's certainly the case that if I create a new account on the
SS20 with a UID <= 100, and then try to mount from one of
these clients using the account, I get a failure. And that if I
then change the UID of the account to something > 100, all is
fine. The closest I can find to an account of this in the
Answerbook is the statement the (in the 'User Accounts, Printers...'
section of the System Administrator Answerbook) that 'Customarily,
the numbers for regular user accounts range from 100 through
60000 and the numbers from 0 through 99 are reserved for system
accounts'. Apart from the apparent off-by-one error, I guess I
would've used a stronger qualifying term than 'customarily'.

Thanks to:

Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz>
Jim Harmon <jharmon@telecnnct.com>
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
rangern@CIRANO.UMontreal.CA (Normand Ranger)
D.White@mcs.surrey.ac.uk

My original query and the responses below.

Thanks again for the help, Mark

Mark Francillon
Marlboro College
markf@marlboro.edu

Roll 'em:

>From sun-managers-relay@ra.mcs.anl.gov Thu Apr 17 15:46 EDT 1997
Date: Thu, 17 Apr 1997 14:06:10 -0400
From: markf@marlboro.edu (Mark Francillon)
To: sun-managers@ra.mcs.anl.gov
Subject: strange NFS rejections on per-user basis

I recently bought and started experimenting with a couple Mac
(Intercon) and PC (Intergraph) NFS clients, the innocent idea
being to let Macs and PCs access file systems on a SS20 running
Solaris 2.4.

Everything works perfectly, absolutely perfectly--for some users.
But for others the client always reports an authentication failure.
This happens even though you can successfully telnet into the
problem accounts; even though you can ftp into those accounts;
and it happens even if you change the passwords on them (I also
don't see any problems with the group memberships for the accounts
in questions).

The frosting on the cake is that the only known 'problem accounts'
are two of the four (non-root) accounts that I regularly use. I've
tried (or had others try) maybe two dozen other account, all
without incident.

Any hints on where I should start looking for the cause of this
kind of selective... obstinacy?

Thanks,

Mark

Mark Francillon
Marlboro College
markf@marlboro.edu

>From ray@isor.vuw.ac.nz Thu Apr 17 17:49 EDT 1997
From: Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz>
Date: Fri, 18 Apr 1997 09:48:41 +1200 (NZST)
To: markf@marlboro.edu
Subject: Re: strange NFS rejections on per-user basis

Check the UID's. I understand that there is something 'special' about
UIDs less than 100 on a SOlaris system.

Hope this helps,
Ray Brownrigg <ray@isor.vuw.ac.nz> http://www.isor.vuw.ac.nz/~ray

>From jharmon@telecnnct.com Thu Apr 17 17:52 EDT 1997
Date: Thu, 17 Apr 1997 17:32:12 -0400
From: Jim Harmon <jharmon@telecnnct.com>
Mime-Version: 1.0
To: Mark Francillon <markf@marlboro.edu>
Subject: Re: strange NFS rejections on per-user basis
Content-Transfer-Encoding: 7bit

Mark Francillon wrote:
>
> I recently bought and started experimenting with a couple Mac
> (Intercon) and PC (Intergraph) NFS clients, the innocent idea
> being to let Macs and PCs access file systems on a SS20 running
> Solaris 2.4.
>
> Everything works perfectly, absolutely perfectly--for some users.
> But for others the client always reports an authentication failure.
> This happens even though you can successfully telnet into the
> problem accounts; even though you can ftp into those accounts;
> and it happens even if you change the passwords on them (I also
> don't see any problems with the group memberships for the accounts
> in questions).

What you aren't telling us is what combination of user/equipment seems
to be failing.

Is it just non-root login from MAC, or just non-root login from TD or
what?

Are the MAC's using NFS?

What NFS program(s) are the TD's using?

You need to tell us explicitly what's happening, what you describe is
like:

I have a box full of nuts and bolts but 10% of them can't connect
together.

What that didn't tell us is that the 10% of unusable nuts and bolts are
metric, not SAE, and the metric bolts are 9mm-diameter with a
10-thread-per-cm groove, while the metric nuts are 8mm-diameter with a
6-thread-per-cm groove.

>
> The frosting on the cake is that the only known 'problem accounts'
> are two of the four (non-root) accounts that I regularly use. I've
> tried (or had others try) maybe two dozen other account, all
> without incident.
>
> Any hints on where I should start looking for the cause of this
> kind of selective... obstinacy?

determine the following:

what are you trying to do; login, mount FS, rlogin, ftp, or what?

from what platform pc, or mac to what paltform (SS20)

from what account on pc, on mac to what account on SS20

what are the differences between the .login, .profile, .cshrc, .<other
rc> .rhosts files in the working accounts, and in the non-working
accounts.

Can you PING the SS20 from ALL pc's.

Can you PING the macs and PCs from the SS20

I appologize for the abrupt and short statements... I'm in the middle of
a number of very confusing issues myself.... and I'm starting to get
tired. :)

> Thanks,
>
> Mark
>
> Mark Francillon
> Marlboro College
> markf@marlboro.edu

-- 
   Jim Harmon                           The Telephone Connection
jim@telecnnct.com                          Rockville, Maryland

>From jharmon@telecnnct.com Thu Apr 17 19:21 EDT 1997 Date: Thu, 17 Apr 1997 19:11:08 -0400 From: Jim Harmon <jharmon@telecnnct.com> Mime-Version: 1.0 To: Mark Francillon <markf@marlboro.edu> Subject: Re: strange NFS rejections on per-user basis Content-Transfer-Encoding: 7bit

Mark Francillon wrote: > > > > Mark Francillon wrote: > > > > Everything works perfectly, absolutely perfectly--for some users. > > > But for others the client always reports an authentication failure. > > > This happens even though you can successfully telnet into the > > > problem accounts; even though you can ftp into those accounts; > > > and it happens even if you change the passwords on them (I also > > > don't see any problems with the group memberships for the accounts > > > in questions). > > > > What you aren't telling us is what combination of user/equipment seems > > to be failing. > > What I meant to convey by 'Everything works perfectly...' was that > from *every* Mac and from *every* PC that I've tried this on, when I > try to mount a file system being shared by the SS20, the NFS client > invariably rejects me when I try to authenticate myself as one of a > certain set of users (only two known so far), and invariably accepts me > when I (or someone else) use some other account.

OK, That brings up the next questions:

Is this NIS, NIS+, Novell, or some other naming service?

What do you get when you "ypcat passwd | grep <failed username>"?

Do the "good" acounts work from the same machines as the "bad ones" that fail?

At this point I want to ask of the accounts you're trying to connect with are NIS accounts, or are they local to the machines you're trying to mount the SS20 FS's on?

I'm thinking that the "good" accounts are "trusted" in the NIS database, and the "bad" ones are local (to the PC or MAC) accounts that the SS20 doesn't know.

> > > I appologize for the abrupt and short statements... I'm in the middle of > > a number of very confusing issues myself.... and I'm starting to get > > tired. :) > > No problem, I'll be more explicit next time > > Mark > > p.s. I got an interesting lead from someone in NZ who says UIDs < 100 > have a funky status under Solaris, which may be the answer if < 100 > really turns out to mean <= 100.

-- Jim Harmon The Telephone Connection jim@telecnnct.com Rockville, Maryland

>From kevin@uniq.com.au Thu Apr 17 20:00 EDT 1997 From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child}) Date: Fri, 18 Apr 1997 09:59:57 EST To: markf@marlboro.edu (Mark Francillon) Subject: Re: strange NFS rejections on per-user basis

Try snoop between the boxes as the transaction proceeds. It is usualy a wealth of information on protocol stuff like this.

l & h, kev

>From rangern@CIRANO.UMontreal.CA Fri Apr 18 08:56 EDT 1997 From: rangern@CIRANO.UMontreal.CA (Normand Ranger) Subject: Re: strange NFS rejections on per-user basis To: markf@marlboro.edu Date: Fri, 18 Apr 1997 08:56:18 -0400 (EDT) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

> > > I recently bought and started experimenting with a couple Mac > (Intercon) and PC (Intergraph) NFS clients, the innocent idea > being to let Macs and PCs access file systems on a SS20 running > Solaris 2.4. > > Everything works perfectly, absolutely perfectly--for some users. > But for others the client always reports an authentication failure. > This happens even though you can successfully telnet into the > problem accounts; even though you can ftp into those accounts; > and it happens even if you change the passwords on them (I also > don't see any problems with the group memberships for the accounts > in questions). > > The frosting on the cake is that the only known 'problem accounts' > are two of the four (non-root) accounts that I regularly use. I've > tried (or had others try) maybe two dozen other account, all > without incident. > > Any hints on where I should start looking for the cause of this > kind of selective... obstinacy? > > Thanks, > > Mark > > Mark Francillon > Marlboro College > markf@marlboro.edu > Did you verify if the partition of these users (/export/home...) have sharing permissions for these PC? Meaning that in your /etc/dfs/dfstab file you have a line like this: share -F nfs -o rw=_PC_names_ /export/home...

Good luck...

Bye.

Normand Ranger `'``' Informaticien-statisticien (o O) --------------------------------------------------------------ooO-(_)-Ooo----- * CIRANO * $$$$$ Centre Interuniversitaire de Recherche en ANalyse des Organisations *$$ $ 2020 rue University, 25e etage, $$** Montreal (Quebec) Canada H3A 2A5 $$ ** Tel: (514)985-4009 FAX: (514)985-4039 $$** E-mail: rangern@cirano.umontreal.ca *$$ $ WWW: http://www.cirano.umontreal.ca/~rangern * $$$$$ * "Quand vient un saint nouveau, on oublie l'ancien" (Proverbe allemand, W. Wander, 1880)

>From css1dw@ee.surrey.ac.uk Fri Apr 18 11:50 EDT 1997 From: D.White@mcs.surrey.ac.uk To: markf@marlboro.edu (Mark Francillon) Subject: Re: strange NFS rejections on per-user basis cc: D.White@mcs.surrey.ac.uk Mime-Version: 1.0 Date: Fri, 18 Apr 1997 16:50:25 +0100

Hi Mark,

In message <199704171806.OAA07123@ marlboro.edu>you write: > >I recently bought and started experimenting with a couple Mac >(Intercon) and PC (Intergraph) NFS clients, the innocent idea >being to let Macs and PCs access file systems on a SS20 running >Solaris 2.4. > >Everything works perfectly, absolutely perfectly--for some users. >But for others the client always reports an authentication failure. >This happens even though you can successfully telnet into the >problem accounts; even though you can ftp into those accounts; >and it happens even if you change the passwords on them (I also >don't see any problems with the group memberships for the accounts >in questions). > >The frosting on the cake is that the only known 'problem accounts' >are two of the four (non-root) accounts that I regularly use. I've >tried (or had others try) maybe two dozen other account, all >without incident. > >Any hints on where I should start looking for the cause of this >kind of selective... obstinacy?

I just wonder if you're in too many groups (more than 8 or 16?)? If it's your accounts giving the trouble, you may well have put yourself into lots of groups.

I had this problem between Solaris and DEC Unix the other day!

>Thanks, > >Mark > >Mark Francillon >Marlboro College >markf@marlboro.edu

cheers, duncan

------------------------------------------------------------------------------ Duncan C. White, Senior Computing Officer, Dept of Maths and Computing Science, University of Surrey, Guildford, Surrey GU2 5XH, UK. Email: D.White@mcs.surrey.ac.uk Phone: +441 483 259632 URL: http://www.mcs.surrey.ac.uk/showstaff?D.White Fax: +441 483 259385

PGPkey: http://www.mcs.surrey.ac.uk/Personal/D.White/pgpkey.html Key fingerprint = 91 93 0D 90 D0 5E 62 BF 57 39 08 56 43 FC E5 C8 ------------------------------------------------------------------------------ "After all, this is a species whose principal means of population control are famine, abortion, a high infant death rate and war." Intervention (page 442) - Julian May ------------------------------------------------------------------------------



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:51 CDT