2002-08-13 11:44:22

by george drossos

[permalink] [raw]
Subject: nfs problem



I'm a student in South Bank University London and i,m working on a project
"distibuted and parallel processing in Linux".
I tried to set up NFS(i have 1 server and 2 clients).
My kernel version is 2.4.18-3 and i installed red.hat 7.3.I didn't install
any other operation system.
I check that nfs is running on the server(all the daemons as start-up
scripts)and i ckeck that nfs is running on the clients as well.
I edit /etc/exports i wrote the directory that i want to export and the
destination hosts.
About the clients,the mount version is 2.10n,nfs daemons are running.
I red the file /proc/filesystems if nfs was there,it wasn't but appeared by
typing insmod nfs.I check again the services by typing rpcinf -p and
everything was ok.
When i try to mount the remote directory i have error message:
mount:RPC:Port mapper failure-RPC:Unable to receive

I checked again that NFS was running in three machines and afterwards i
typed on each client:
rpcinfo -p servername
the error message was:
rpcinfo:can't contact portmapper:RPC remote system error:Connection
refused

Also i want to say in the case that there is a routing problem,i ping the
machines and everything is ok.The only problem that i have until now is that
i cannot connect the clients with the university's network.When i ping the
default gateway (from the clients) says Network is unreachable.In the case
of server(has 2 network cards) i ping everything and the university network
is reachable.

I would really appreciate replying and i'm really looking forward your
suggestions and advices.

George Drossos


_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail.
http://www.hotmail.com



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs


2002-08-13 14:34:30

by Neal Lippman

[permalink] [raw]
Subject: nfs permissions / access problem

I am hoping someone can provide some advice. The situation is that I want to
have available on my nfs server a share that is accessible to a group of
people connecting from their workstations, but am having trouble doing so.

Following what I would have done for a local directory, I created the
directory: /shared and set its ownship to root, with group=sharedgroup, and
then gave group permissions of rwx. I made sure each user who needs to use
the shared directory is in the sharedgroup on the server, and for good
measure also did so on each workstation (and yes, the gid's are the same on
each machine). Unfortunately, the directory remains inaccessible via nfs with
this scheme.

I suspect the problem here is that nfs receives from the client the uid and
gid that the client process is currently executing under, but does not
received the extended group list, and also does not look up that user's
extended group list on the server but rather just does permission checking
with the single active uid and gid it received from the client, and so cannot
access via extended group information.

That doesn't strike me as the best way for nfs to operate, although I am am
sure there was sound design decision involved (maybe overhead of looking up
the groups on each access, which the os does not have locally as that info is
already in the process's state information, placed there at login).

In any case, it means that I cannot easily export a shared directory in this
fashion.

So my question is: How do I make an exported folder accessible to a group of
users?

Thanks.
nl


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2002-08-13 15:19:45

by Daniel Brunner

[permalink] [raw]
Subject: Re: nfs permissions / access problem

Hello!!

What's you /etc/exports look like!?!?

/shared 195.168.100.0/255.255.255.0(rw)
....


Use whatever your ip number is...


Dan



On Tuesday, August 13, 2002, at 09:38 AM, [email protected] wrote:

> I am hoping someone can provide some advice. The situation is that I
> want to
> have available on my nfs server a share that is accessible to a group of
> people connecting from their workstations, but am having trouble doing
> so.
>
> Following what I would have done for a local directory, I created the
> directory: /shared and set its ownship to root, with group=sharedgroup,
> and
> then gave group permissions of rwx. I made sure each user who needs to
> use
> the shared directory is in the sharedgroup on the server, and for good
> measure also did so on each workstation (and yes, the gid's are the
> same on
> each machine). Unfortunately, the directory remains inaccessible via
> nfs with
> this scheme.
>
> I suspect the problem here is that nfs receives from the client the uid
> and
> gid that the client process is currently executing under, but does not
> received the extended group list, and also does not look up that user's
> extended group list on the server but rather just does permission
> checking
> with the single active uid and gid it received from the client, and so
> cannot
> access via extended group information.
>
> That doesn't strike me as the best way for nfs to operate, although I
> am am
> sure there was sound design decision involved (maybe overhead of
> looking up
> the groups on each access, which the os does not have locally as that
> info is
> already in the process's state information, placed there at login).
>
> In any case, it means that I cannot easily export a shared directory in
> this
> fashion.
>
> So my question is: How do I make an exported folder accessible to a
> group of
> users?
>
> Thanks.
> nl
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2002-08-13 17:42:56

by Heflin, Roger A.

[permalink] [raw]
Subject: RE: nfs permissions / access problem




> Message: 4
> From: Neal Lippman <[email protected]>
> Reply-To: [email protected]
> To: [email protected]
> Date: Tue, 13 Aug 2002 10:38:08 -0400
> Subject: [NFS] nfs permissions / access problem
>=20
> I am hoping someone can provide some advice. The situation is that I =
want to=20
> have available on my nfs server a share that is accessible to a group =
of=20
> people connecting from their workstations, but am having trouble doing =
so.
>=20
> Following what I would have done for a local directory, I created the=20
> directory: /shared and set its ownship to root, with =
group=3Dsharedgroup, and=20
> then gave group permissions of rwx. I made sure each user who needs to =
use=20
> the shared directory is in the sharedgroup on the server, and for good =

> measure also did so on each workstation (and yes, the gid's are the =
same on=20
> each machine). Unfortunately, the directory remains inaccessible via =
nfs with=20
> this scheme.
>=20
Comment #1: The uid/gid on the server does not matter, it is not =
necessary for
a user to even exist on the server, the gid/uid must exist on the =
client as
this is all that actually matters, and the permissions to the given =
directory
must allow said user to put a file in the directory in question. In =
NFS the server
basically trusts that the user on the client is who they say they are.

You were able to mount the disk on the clients correct? And you did =
have
the users (on the clients) logout after adding a new group to their =
username on
the workstation?=20
=20
You will only get the groups that you had during your initial login, =
new groups=20
added later are not going to be used until a logout/login. The =
groups=20
command will report that you are a member of the new group, but without =
a=20
logout/login it is wrong. Groups does not check to see what gid's the =
user
has, it checks to see what groups you would have if you currently =
logged in.
From alot of what you have said, I think you have a unclear =
understanding of=20
exactly how NFS works (and most other network file systems).

I would also suggest since you are going to all of the trouble of =
maintaining
separate password/group files that you investigate NIS or something =
similar,
as this simplifies things, and makes everything at lot less work.

> I suspect the problem here is that nfs receives from the client the =
uid and=20
> gid that the client process is currently executing under, but does not =

> received the extended group list, and also does not look up that =
user's=20
> extended group list on the server but rather just does permission =
checking=20
> with the single active uid and gid it received from the client, and so =
cannot=20
> access via extended group information.
>=20
No lookup is ever done on the server for gid/uid on any implementation =
of=20
NFS I know of, the listed uid/gid is compared to the permissions on the =

directory.

> That doesn't strike me as the best way for nfs to operate, although I =
am am=20
> sure there was sound design decision involved (maybe overhead of =
looking up=20
> the groups on each access, which the os does not have locally as that =
info is=20
> already in the process's state information, placed there at login).
>=20
This is because you don't understand exactly how nfs is used, it works
exactly like the normal unix file permission setup, doing anything else =

would make it inconsistant with the way unix file permissions work.

> In any case, it means that I cannot easily export a shared directory =
in this=20
> fashion.
>=20
As you describe things it should work, if everything is done correctly.

> So my question is: How do I make an exported folder accessible to a =
group of=20
> users?
>=20
> Thanks.
> nl
>=20


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2002-08-13 18:08:31

by Frank van Maarseveen

[permalink] [raw]
Subject: Re: nfs permissions / access problem

On Tue, Aug 13, 2002 at 10:38:08AM -0400, Neal Lippman wrote:
>
> Following what I would have done for a local directory, I created the
> directory: /shared and set its ownship to root, with group=sharedgroup, and
> then gave group permissions of rwx. I made sure each user who needs to use
> the shared directory is in the sharedgroup on the server, and for good
> measure also did so on each workstation (and yes, the gid's are the same on
> each machine). Unfortunately, the directory remains inaccessible via nfs with
> this scheme.

Just a guess:

Only the first 16 groups ids of the secondary group list are sent to the
server (RPC protocol limitation). Try the

groups

command and when "sharedgroup" is the seventeenth or more on the
NFS client then it's the cause of the problem. In that case, see
http://web.inter.nl.net/users/fvm for a patch or re-arrange the group
memberships.

--
Frank


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs