Hello,

I have set up a server, so that I can learn how to run all the major services. I have about 4 other computers in addition to the server.
Right now I have only NFS running (one thing at a time).

I was able to set it up without major problems by following the NFS-Howto.

I ran into a problem on the client side with permissions, and was able to solve the problem, BUT I believe this is probably not the best way to solve this problem.

What I did was the following. I crated the same user id on the server that I have on the client, lets call it JR100 with the same uid and gid.
I then changed the exported directory on the server to be owned by JR100. Now I can read and write from the client to the directory on the server.

I DO NOT run NIS yet, so it just does not seem right that I should have to do this.

Can someone tell me if there is a better way of doing this, I am sure there must be.

Sorry for the long post:

Client is running Suse 10
Server is running ubuntu 6.06
rpcinfo -p reports nfs version 2, 3, 4 running on default port

Thanks.

Files when created have a numeric UID (user ID) associated with them. The UID is the number you see in /etc/passwd next to the user ID (the second number is the Group ID, GID). Since the files always have the UID then access to the files is based on the UID (remember directories are considered to be "files" in this context). So of course you have to have the same UID on the other server to access them with no special options.

This is not restricted to NFS. If you tar up files on one host then restore them to another host they will have the first host's UID on them. If that UID user doesn't exist on the target host they would only be accessible to root. Also you'll see the UID number as the owner of the files on the 2nd host rather than the name because the name is not stored on the file - only the UID is stored.

NFS unlike tar would not let root access NFS files by default.
You can however export from the NFS server host with root permissions so that root on the NFS client host can access them.

it sounds to me like you did it right.

funny that sometimes there are questions even when everything works.

Ok, so that means that I have to create user ids on the server for every uid/gid on the client side.

What about when I want to share a directory (rw) between multiple users. Will I have to open up that directory drwxrwxrwx, or is there some other way.

give all those users the same group/gid as the JR100 user.

Same UID is not a good idea. Same GID is. Groups are designed exactly to allow multiple users to share files they need to access in common. Instead of drwxrwxrwx (777) you give the files drwxrwx--- (770) and put all the users in the same group.

Giving all the users the same UID doesn't work because only the first user NAME will be associated with the UID. It will appear as if all users are that first user. If you're going to do something like that there is little reason to have separate user accounts and you might as well just create the first user and give everyone the password for it. Note that I'm not saying to do this - just saying it is not much different from giving them the same UID.

It does occur that on occasion you do wish to give multiple "real" users access to the same "administrative" user account. (e.g. "oracle" for database administrators). The best way to handle that is to create a user ID for each of the "real" users then setup a sudo ers file that allows each of these "real" users to "su -" to the "administrative" account (e.g. "su - oracle"). By using sudo you can tell which "real" user logged in to become the "administrative" user because sudo does logging. You can restrict it even further by setting up the commands needed to run as the "administrative" user instead of just doing the "su - oracle " you could do "su - oracle -c sql".

I had the same problem.

Solved it by using 'anonuid=xxx,anongid=yyy' in /etc/exports, where xxx and yyy are the UID and GID of the files owner on the server.