Re: [gentoo-user] [nfs] nfs mount settings

[Alan McKinnon]

On Monday 27 July 2009 03:18:34 Harry Putnam wrote:
> I'm not that familiar with nfs usage ... only used lightly a few
> times.
>
> I have an opensolaris nfs server serving a share to my gentoo box.
>
> The mount point is set as owner:group  of my user (reader).
>
> Also has the set-gid bit set.
>
> ls -ld /projects
> drwxr-sr-x 2 reader wheel 48 Jun 24 07:08 /projects
>
> And the mount settings in /etc/fstab
> (zfs is the hostname of the opensolaris server)
>
> zfs:/projects   /projects    nfs   noauto,users,exec,dev     0 0
>
> With those settings my user or root can mount it.
>
> When its mounted the permissions change to this:
>
> ls -ld /projects
> drwxr-sr-x+ 13 reader man 14 Jul 25 09:47 /projects
>
> Whats with the `man' group?

The way nfs works is that it takes a remote filesystem and *mounts* it 
locally, exactly as if it were a local filesystem. It is not a share. The 
inodes are exported over nfs and that directory is owned by a group with gid 
of say X. On your local machine that gid just happens to be the man group.

There is nothing much you can do about this except:

Renumber your gid's locally to match the nfs server,
or renumber the nfs share gids to match your local machine

> Also, when mounted I find when I try to copy somethihng with the -a
> option, which tries to maintain any permission settings.  It causes an
> error warning... (although the copy is done).
>
>  cp -a file file1
>   cp: preserving permissions for `file1': Operation not supported

Full paths please. I can't see which way the copy is going.

I suspect that your user on the nfs server is not a member of the group that 
has the same gid as your local man group.
>
> And the files permissions end up:
>  ls -l file*
> -rw-r--r--+ 1 reader man    223962 Jul 26 15:56 file
> -rw-r--r--+ 1 reader reader 223962 Jul 26 15:56 file1
>
> Is there some way to set it up so that permissions can be copied?
> Also to alow the set-gid setting to work?


Golden rule with nfs:

It was designed for the case of a diskless client mounts it's home or root 
directories over the network, while exporting passwd and shadow files over 
NIS. That is evident in it's design and there is no facility to change uids 
and gids on the fly. You do not authenticate with nfs, the server assumes that 
the request coming from the client is OK and treats it exactly as it would a 
request from a local user on a local disk. This is the primary reason why nfs 
performs so well.

It is up to you to make sure your uids and gids everywhere match and work. nfs 
cannot and will not help with this.

-- 
alan dot mckinnon at gmail dot com