[gentoo-user] [nfs] nfs mount settings

[gentoo-user] [nfs] nfs mount settings

[Harry Putnam]

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?

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

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?

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

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

[Harry Putnam]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> 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

Looking into that I noticed, as you thought the gid of the share on
solaris is alphabetic wheel but numeric 15.   Which is the gid of
`man' on gentoo.

But I noticed the gid 16 is not taken on the gentoo os so promoted man
to gid 16 and changed wheel from 10 to 15.

Logging my user out and back in I see the gid 15 now is wheel so the
same as solaris.

Having my user mount the nfs ... it ends up `reader:wheel'.  Both are
my users uid and one of his gids so now both the uid and gid match
those on the solaris OS where user reader:wheel owns the source
directory. (also /projects on solaris box).

But with all that in place.... a copy using `-a' still causes the the
same error warning.

  ls -l /projects/it
  -rw-r--r--+ 1 reader wheel 0 Jul 27 09:17 /projects/it

 cp -a /projects/it /projects/it2
 cp: preserving permissions for `/projects/it2': 
     Operation not supported

  ls -l /projects/it2
  -rw-r--r--+ 1 reader wheel 0 Jul 27 09:17 /projects/it2

 ==============================================

  user reader (on gentoo) running command id -a
  uid=1000(reader) gid=1000(reader) groups=15(wheel),16(man),
                                    250(portage),1000(reader)

  user reader (on solaris) running command id -a
  uid=1000(reader) gid=10(staff) groups=10(staff),3(sys),4
                                 (adm),15(wheel)

 ==============================================

And the nfs source directory is also set-gid (by user reader)
  ls -ld /projects (on solaris server)
  drwxr-sr-x 14 reader wheel 17 2009-07-27 09:29 /projects

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

[Alan McKinnon]

On Monday 27 July 2009 16:40:43 Harry Putnam wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> writes:
> > 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
>
> Looking into that I noticed, as you thought the gid of the share on
> solaris is alphabetic wheel but numeric 15.   Which is the gid of
> `man' on gentoo.
>
> But I noticed the gid 16 is not taken on the gentoo os so promoted man
> to gid 16 and changed wheel from 10 to 15.
>
> Logging my user out and back in I see the gid 15 now is wheel so the
> same as solaris.

When you do this, you only change the username attached to the gid. Remember 
that the filesystem does not know or care what username you use, it only knows 
about gids. You now need to find every file group owned by man's old gid and 
chown it to man's new gid. Put another way, the man groups files now appear to 
belong to the wheel group, and the wheel group's files are orphaned. This 
ought to do it:

- umount nfs shares
- find / -gid 15 -exec chown :16 {} +;
- find / -gid 10 -exec chown :15 {} +;
- mount nfs shares

You must establish for yourself if any files were created meanwhile with gid 
10 or 15 and take steps to deal with those specially.

> Having my user mount the nfs ... it ends up `reader:wheel'.  Both are
> my users uid and one of his gids so now both the uid and gid match
> those on the solaris OS where user reader:wheel owns the source
> directory. (also /projects on solaris box).
>
> But with all that in place.... a copy using `-a' still causes the the
> same error warning.

Let's try something stupid :-)

cp -a is a GNU extension IIRC, and Solaris userland does not support it. 
Try cp -pr just for fun

Also, there's an ACL on that file (the +). What are those rules, determined by 
getfacl? It shouldn't make a difference as ACLs cannot take away a user's 
permissions. But SELinux can ... offhand I cannot think of anything on Solaris 
that works similarly - anything ring a bell here about your nfs server?

What are your mount options on the client side, and the relevant line in 
exports on the server side?

>
>   ls -l /projects/it
>   -rw-r--r--+ 1 reader wheel 0 Jul 27 09:17 /projects/it
>
>  cp -a /projects/it /projects/it2
>  cp: preserving permissions for `/projects/it2':
>      Operation not supported
>
>   ls -l /projects/it2
>   -rw-r--r--+ 1 reader wheel 0 Jul 27 09:17 /projects/it2
>
>  ==============================================
>
>   user reader (on gentoo) running command id -a
>   uid=1000(reader) gid=1000(reader) groups=15(wheel),16(man),
>                                     250(portage),1000(reader)
>
>   user reader (on solaris) running command id -a
>   uid=1000(reader) gid=10(staff) groups=10(staff),3(sys),4
>                                  (adm),15(wheel)
>
>  ==============================================
>
> And the nfs source directory is also set-gid (by user reader)
>   ls -ld /projects (on solaris server)
>   drwxr-sr-x 14 reader wheel 17 2009-07-27 09:29 /projects

-- 
alan dot mckinnon at gmail dot com

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

[Harry Putnam]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

[...]

>> Logging my user out and back in I see the gid 15 now is wheel so the
>> same as solaris.
>
> When you do this, you only change the username attached to the gid. Remember 
> that the filesystem does not know or care what username you use, it only knows 
> about gids. You now need to find every file group owned by man's old gid and 
> chown it to man's new gid. Put another way, the man groups files now appear to 
> belong to the wheel group, and the wheel group's files are orphaned. This 
> ought to do it:

> - umount nfs shares
> - find / -gid 15 -exec chown :16 {} +;

Not many files have group man... mainly /var/cache/man/*

> - find / -gid 10 -exec chown :15 {} +;
> - mount nfs shares

I'm working on that... but that would only get to files NOT on the nfs
mount.  Far as on the nfs mount...where the `cp -a' problem is, the
numeric gids are the same on all machines now.

[...]

>> But with all that in place.... a copy using `-a' still causes the the
>> same error warning.
>
> Let's try something stupid :-)

> cp -a is a GNU extension IIRC, and Solaris userland does not support it. 
> Try cp -pr just for fun

The server is opensolaris.. which has lots of gnus tools... including
cp -a, but just making sure:

 cd /projects
 touch file
 cp -rp file file2
  cp: preserving permissions for `file2': Operation not supported

> Also, there's an ACL on that file (the +). What are those rules, determined by 
> getfacl? It shouldn't make a difference as ACLs cannot take away a user's 
> permissions. But SELinux can ... offhand I cannot think of anything on Solaris 
> that works similarly - anything ring a bell here about your nfs server?

getfacl doesn't show anything as an acl...
  getfacl file 
  # file: file
  # owner: reader
  # group: wheel
  user::rw-
  group::r--
  mask::rwx
  other::r--

> What are your mount options on the client side, and the relevant line in 

I posted those already.. `noauto,users,exec,dev,suid'

> exports on the server side?

opensolaris running zfs filesystem doesn't use an exports list.

nfs exporting is done by using the: 

`zfs set sharenfs=on'  cmd on the desired member of a zfs filesystem.

I don't really know what the defaults are and not really sure how to
find out either.

I've run into something more serious in the course of investigating
about the nfs mount...  a reboot of gentoo has shown that I have no
keyboard or mouse once I turn X on.  

So the nfs stuff will have to wait.... its working well enough for me
to work on the mounted filesystem for now anyway.

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

[Alex Schuster]

Alan McKinnon writes:

> 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. 

man 5 exports (at least my localized german version) lists the map_daemon 
option, which allows mapping of UIDs / GIDs between server and client. This 
needs the rpc.ugidd to be running on server side.
I never did this, I don't even know where to get rpc.ugidd from, and I'm 
pretty sure it won't work at all with opensolaris, but at least with linux 
it should be possible then, theoretically.

	Wonko

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

[Alan McKinnon]

On Tuesday 28 July 2009 09:39:40 Alex Schuster wrote:
> Alan McKinnon writes:
> > 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.
>
> man 5 exports (at least my localized german version) lists the map_daemon
> option, which allows mapping of UIDs / GIDs between server and client. This
> needs the rpc.ugidd to be running on server side.
> I never did this, I don't even know where to get rpc.ugidd from, and I'm
> pretty sure it won't work at all with opensolaris, but at least with linux
> it should be possible then, theoretically.
>
> 	Wonko

That's good to know - I don't have anything like that here in my man pages.

I have nfs-utils-1.2.0, what version are you running?

-- 
alan dot mckinnon at gmail dot com

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

[Alex Schuster]

Alan McKinnon writes:

> On Tuesday 28 July 2009 09:39:40 Alex Schuster wrote:

> > man 5 exports (at least my localized german version) lists the
> > map_daemon option, which allows mapping of UIDs / GIDs between server
> > and client. This needs the rpc.ugidd to be running on server side.
> > I never did this, I don't even know where to get rpc.ugidd from, and
> > I'm pretty sure it won't work at all with opensolaris, but at least
> > with linux it should be possible then, theoretically.

> That's good to know - I don't have anything like that here in my man
> pages.

Well, at east the sed man page in german is quite different from the 
englisch one, maybe that's the case here, too. Does yours explain the 
(no_)subtree_check option? I had t look them up online.

> I have nfs-utils-1.2.0, what version are you running?

1.1.4-r1. 

Bug #116269 from end of 2005 misses the rpc.ugidd, the answer there is that 
nfs-utils does not yet support it. And I doubt it ever will, I just read 
that this is a feature of user space NFS, which seems to be deprecated. A 
kernel based NFS does not have it.

So, so seem to be right, ID mapping just is not possible (any more).

But what about NFS v4? Is has user authentification, maybe then there's a 
mapping feature, too?

	Wonko

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

[Stroller]

On 27 Jul 2009, at 02:18, Harry Putnam wrote:
> ...
> 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).
> ...
> ls -ld /projects
> drwxr-sr-x 2 reader wheel 48 Jun 24 07:08 /projects
>
> ...
> When its mounted the permissions change to this:
>
> ls -ld /projects
> drwxr-sr-x+ 13 reader man 14 Jul 25 09:47 /projects

Further to A McK's reply, suggest use of `ls -ln`.

Assuming the -n is supported on Slowaris all will become clear.

Stroller.

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

[Harry Putnam]

Stroller <stroller@stellar.eclipse.co.uk> writes:

> Further to A McK's reply, suggest use of `ls -ln`.
>
> Assuming the -n is supported on Slowaris all will become clear.
>

But after the changes mentioned in a reply to Alan M.  it now shows
the same on both the source /projects (on solaris) and the mounted nfs
/projects on gentoo.

ls -ln (on solaris)

   ls -ln /projects
total 18
drwxr-xr-x  2 1000 10   5 2009-07-25 18:46 bookmks
drwxrwxrwx  9 1000 15  10 2009-07-13 08:38 harvey
drwxr-xr-x  3 1000 15   3 2009-01-21 18:22 mob1
drwxr-xr-x 32 1000 15  34 2009-06-24 07:35 reader_rdr
[...]

=====================================================

ls -ln (on gentoo)

total 18
drwxr-xr-x+  2 1000 10   5 Jul 25 18:46 bookmks
drwxrwxrwx   9 1000 15  10 Jul 13 08:38 harvey
drwxr-xr-x+  3 1000 15   3 Jan 21  2009 mob1
drwxr-xr-x+ 32 1000 15  34 Jun 24 07:35 reader_rdr
[...]

The only difference I see is the `+' on gentoo.  I'm not sure what
that means.

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

[Alan McKinnon]

On Monday 27 July 2009 16:47:30 Harry Putnam wrote:
> Stroller <stroller@stellar.eclipse.co.uk> writes:
> > Further to A McK's reply, suggest use of `ls -ln`.
> >
> > Assuming the -n is supported on Slowaris all will become clear.
>
> But after the changes mentioned in a reply to Alan M.  it now shows
> the same on both the source /projects (on solaris) and the mounted nfs
> /projects on gentoo.
>
> ls -ln (on solaris)
>
>    ls -ln /projects
> total 18
> drwxr-xr-x  2 1000 10   5 2009-07-25 18:46 bookmks
> drwxrwxrwx  9 1000 15  10 2009-07-13 08:38 harvey
> drwxr-xr-x  3 1000 15   3 2009-01-21 18:22 mob1
> drwxr-xr-x 32 1000 15  34 2009-06-24 07:35 reader_rdr
> [...]
>
> =====================================================
>
> ls -ln (on gentoo)
>
> total 18
> drwxr-xr-x+  2 1000 10   5 Jul 25 18:46 bookmks
> drwxrwxrwx   9 1000 15  10 Jul 13 08:38 harvey
> drwxr-xr-x+  3 1000 15   3 Jan 21  2009 mob1
> drwxr-xr-x+ 32 1000 15  34 Jun 24 07:35 reader_rdr
> [...]
>
> The only difference I see is the `+' on gentoo.  I'm not sure what
> that means.

It usually means there's an ACL attached to that dir/file

-- 
alan dot mckinnon at gmail dot com

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

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

Am Montag 27 Juli 2009 03:18:34 schrieb Harry Putnam:
> 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

BTW: The permissions of the mount point don't matter since they can be 
different after the directory has been mounted. So I guess the set-gid only 
needs to be set on the exported directory. In fact, I would set the 
permissions of the mount point so that it's only writable by root so that 
ordinary users can't write to it while it's unmounted (a later mount would 
make those files invisible for as long as the directory is mounted).

And finally: Using the kernel automounter (autofs) avoids
1) the need for the users option
2) users forgetting to mount the thing

Bye...

	Dirk

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]