NFS mounts, UIDs and GIDs mismatches

Hi all,

I am setting up a NFS server on openSuSE 12.2
The export is set fine, I can see it with showmount, I can mount it on the OS X 10.6 client.

I set the following options for the export:

rw,root_squash,sync,no_subtree_check

When I mount the NFS directory on the Mac, it is mounted as readonly. I tried using “-o rw” to no avail.

I suspect this has to do with UIDs, GIDs and usernames not matching on both machines. What is the best way to go to solve this? I would like to do as much as possible on the SUSE server so I don’t have to change too much on the clients for convenience and maintenance sake.
I plan on adding a WinXP and Win7 client later one once I have ironed out the Mac situation.

Thanks for your help,

As I do not know what the Mac does, this is only to tell you about those users/groups.

Users (and groups) are identified by numbers (uid and gid). Those are attached to the files as the owner and group.
Thus when you mount a directory on another system, the owners will still be the number that has some user definition on the exporting machine. E.g. when on the exporting system the owner of a file is uid 1003, then on the NFS cl;ient, the owner is also 1003. But 1003 may be a completely different user on the client then on the server. Maybethat use is not even defined. Thus it may look as if the file system is monted read-only, but in fact some user on the client tries probably to read a file where (s)he is not the owner and has also no read access.

The usernames are of no interest here. Usernames are local to a system and can be seen as the easy to remember and use (for a humman) alias of a userid.

Repeating. When user with uername piet and userid 1003 owns a file with read access for himeself but not for the world and that file is imported on another system where there is also a username peit, butr with userid 1004, piet can not read that file teher.

Using NFS bounds systems close together and you should keep a central user/group administration to prevent this problem (and worse, when user klaas with userid 1003 will be able to do everyting with piet’s files on the client system). You may organise this administartion manualy, but NFS was allways tightly bound to NIS.

Yo could do

ls -ln

to see what the numbers are. E.g. as root on the client (as root so you are not blocked from listing).

ShaolinSatellite wrote:
> Hi all,
>
> I am setting up a NFS server on openSuSE 12.2
> The export is set fine, I can see it with showmount, I can mount it on
> the OS X 10.6 client.
>
> I set the following options for the export:
>
> Code:
> --------------------
> rw,root_squash,sync,no_subtree_check
> --------------------
>
>
> When I mount the NFS directory on the Mac, it is mounted as readonly. I
> tried using “-o rw” to no avail.
>
> I suspect this has to do with UIDs, GIDs and usernames not matching on
> both machines. What is the best way to go to solve this? I would like to
> do as much as possible on the SUSE server so I don’t have to change too
> much on the clients for convenience and maintenance sake.
> I plan on adding a WinXP and Win7 client later one once I have ironed
> out the Mac situation.
>
> Thanks for your help,

I think you have made a classic mistake in posting your request for
help. You have a problem; you then hypothesised a possible cause for the
problem and you made this cause the focus of your efforts and the focus
of your posting title. Thus misleading people as to what your problem is
and wasting everybody’s time.

The reality is that you have a problem with an NFS mount and you don’t
know what the cause is. It is better (I might almost say ‘necessary’) to
establish what the cause actually is before trying to solve the problem.
This is called ‘gathering evidence’.

So the first thing to do is to look in the logs on both the client and
server and see what they say. Increase the log level if necessary (e.g.
do the mount manually with the -v option). Also print and report the
appropriate bits of /proc that detail the nfs options.

FWIW, my hypothesis, which is equally based on no facts, is that your
problem has nothing to do with uids and gids, but instead depends on the
server and client versions and the version of the protocol that is in use.

I mounted with -v and all I am getting is this:

hans:~ hfp$ sudo mount -t nfs -v -o resvport downloader:/home/user/Downloads/complete /Users/hfp/Desktop/dler-nfs/
Password:
downloader:/home/user/Downloads/complete on /Users/hfp/Desktop/dler-nfs (nfs)

How can I get the appropriate bits of /proc that detail the nfs options and check on the server side for verbose logs?

Create a directory on the file system you are exporting, and give it permission 777 (read/write/x for everybody).

Then see if you can create files there on the MAC. If you can, then you have a permissions/uid/gid or something problem. If not, you have a mount problem.

I can read write and delete in the 777 directory so it seems it is a permission/GID/UID related problem after all. What would my next step be?

Best would be to have the same uid and gid for on both systems, at least for the users who need write access to the NFS share. It is probably easier to change uids on the linux system than on the MAC. If you change the uid for a user, you also have to change the uid for all files owned by that user.

Read my post.

Done, thanks for the explanation.

Here is the output

hans:dler-nfs hfp$ ls -ln
total 32
drwxr-xr-x   3 1000  100  4096 29 Sep 19:26 Games
drwxr-xr-x   3 1000  100  4096 30 Sep 11:20 Movies
drwxr-xr-x   3 1000  100  4096  1 Oct 23:22 Music
drwxr-xr-x  14 1000  100  4096  1 Oct 23:19 TV

In the home diretory, on my Mac, I have these numbers

hans:~ hfp$ ls -ln
total 1136
drwxr-xr-x   2 501  20      68 14 Apr 16:54 Applications
drwx------+ 19 501  20     646  1 Oct 20:38 Desktop
drwx------+ 10 501  20     340  5 Aug 19:34 Documents
...]

How can I unify these numbers on both computers? What about these two other computers running Windows 7 and Windows XP that I would like to get this share setup on too?

Isn’t that clear from my story? You should have the same numbers for the same users/groups on both systems. Thus on (at least) one system you must remove the users/groups that are wrong and recreate them with the correct numbers. And of courrse move their data to their new home directories and of course chown newuser:newgroup all of their files. When one does not do this correct from the beginning, one has a nice task to make it OK :frowning:

And about those Windows copmputers I cannot ay much usefull because my Windows knowledge is next to nothing. I had the impression that NFS was not implemented on Windows systems. But when it is, you should look at the docs there to find out how they mimic ownership by user and group.

You either have to change the UID of Dan to 1000 on the MAC, or to 501 on the opensuse system.

It is probably safer to change the 501 to a 1000 than the other way around (less likely to cause any conflict). On the other hand, I don’t use a MAC, so I have no idea what problems you might run into.

With opensuse:

Edit “/etc/passwd” and first make sure that uid of 501 is not in use. If that is okay, then change the 1000 to 500 in the UID field (“man 5 passwd” will give you the format).

Next, you will need:


# cd /home/hans
# chown -R 501 .
# ### (just hope that all files in "/home/hans" were owned by hans)
# cd /var/spool/mail
# chown 501 hans ## but only if the file "hans" exists

You should make all of those changes while hans is not even logged in. At the GUI login prompt, hit ALT-F1, and login as root at a virtual terminal to make the changes.

There are probably also files/directories owned by hans in “/tmp” and “/var/tmp”. As long a hans is not logged in, removing those is probably the simplest.

There might be files owned by hans elsewhere. You could do a recursive find:


# find / -user 1000 -exec chown 501 \{\}\;

That will take a while. I would probably not bother with that, since I would know where the files were that needed changing.

As for Windows - I have no idea what you are doing there. Easiest is to share files with Windows using samba. And for that, uids don’t matter. Windows silently logs the users in using the login name and password (would be in smbpasswd file).

nrickert wrote:
> ShaolinSatellite;2492703 Wrote:
>> How can I unify these numbers on both computers?
>
> You either have to change the UID of Dan to 1000 on the MAC, or to 501
> on the opensuse system.
>
> It is probably safer to change the 501 to a 1000 than the other way
> around (less likely to cause any conflict). On the other hand, I don’t
> use a MAC, so I have no idea what problems you might run into.

Note that some distros, such as Debian, explicitly reserve UIDs below
1000 for system use. Some of their maintenance scripts will delete a
non-system user with a UID < 1000.

> With opensuse:
>
> Edit “/etc/passwd”

Don’t forget to use vipw or some other specific tool, and to adjust
/etc/shadow as well.

> There might be files owned by hans elsewhere.

The UID itself might also occur in other files in /etc - group, exports etc.

And when we most probably will forget one of those places. IMHO removing and recreatiing the user is most save (when you use a good tool like YaST for it, but useradd and friends may do).

A general comment.

A planned way to use NFS will begin with setting up a network database for UID, GID etc (NIS or LDAP or similar). It does not make sense to do NFS without out that.

Home use can be more ad hoc.

What I do at home, is share a partition with NFS for linux systems and with samba for windows systems.

It happens that I use the same UIDs and GIDs on the linux boxes, so that part is easy. For windows users, I allow only anonymous access.

My main intention is: Share things like music, photos, etc. These can be shared read-only, so that matching UIDs doesn’t actually matter.

Additionally, I have a few directories on the share with permissions 777. That way, all clients can upload to those directories or create network backups in those directories. Uploaded files can be later moved from the server, if appropriate. If they are just temporary uploads, then they can be later deleted. If they are backups, they can be copied to a usually off-line external drive.

As you can see, matching UID and GID is not particularly important for this type of use.