about zfs exported on nfs

[Harry Putnam]

summary:

A zfs fs set with smb and nfs on, and set chmod g-s (set-gid) with
a local users uid:gid is being mounted by a remote linux host (and
windows hosts, but not discussing that here).

The remote user is the same as the local user in both numeric UID
and numeric GID

The zfs nfs/cifs share is mounted like this on a linux client:
mount -t nfs -o users,exec,dev,suid

Any files/directories create by the linux user end up with
nobody:nobody uid:gid and any attempt to change that from the client
host fails, even if done as root.

Details:

I'm not sure when this trouble started... its been a while, long
enough to have existed over a couple of builds (b129 b133). But was
not always a problem.

I jumped from 129 to 133 so don't know about builds in between.

I have a zfs_fs .. /projects on zpool z3

this is a hierarchy that is fairly deep but only the top level is zfs.
(Aside: That is something I intend to change soon)

That is, the whole thing, of course, is zfs, but the lower levels have
been created by whatever remote host was working there.

z3/projects has these two settings:
z3/projects sharenfs on
z3/projects sharesmb name=projects

So both cifs and nfs are turned on making the zfs host both a zfs and
nfs server.

Also when z3/projects was created, it was set:
chmod g-s (set gid) right away.

The remote linux user in this discussion has the same numeric UID and
GID as the local zfs user who is owner of /projects

Later, and more than once by now, I've run this command from the zfs
host:
/bin/chmod -R A=everyone@:full_set:fd:allow /projects

to get read/write to work when working from windows hosts.

The filesystem is primarily accessed as an nsf mounted filesystem on a
linux (gentoo linux) host. But is also used over cifs by a couple of
windows hosts.

On the linux client host, `/projects' gets mounted like this:
mount -t nfs -o users,exec,dev,suid

That has been the case both before having the problem and now.

The trouble I see is that all files get created with:
nobody:nobody

as UID:GID, even though /projects is set as normal USER:GROUP of a user
on the zfs/nfs server.

From the remote (we only deal with the linux remote here) any attempt

to change uid:gid fails, even if done by root on the remote.

[Edward Ned Harvey]

Post by Harry Putnam
A zfs fs set with smb and nfs on, and set chmod g-s (set-gid) with
a local users uid:gid is being mounted by a remote linux host (and
windows hosts, but not discussing that here).
The remote user is the same as the local user in both numeric UID
and numeric GID
mount -t nfs -o users,exec,dev,suid
Any files/directories create by the linux user end up with
nobody:nobody uid:gid and any attempt to change that from the client
host fails, even if done as root.

I don't know if there is something deeper going on here, I'll just start by
saying I'm doing the same thing (but the server is solaris) and I don't have
any problems. This has been in production for quite some time, and used
heavily by many users and various nfs clients. It's rock solid, and
everyone loves it. Very tried and tested. ;-) Here is how I am set up:

Filesystem exported by the following line in /etc/dfs/dfstab:
share -F nfs -o
rw=someclient.domain.com,root=someclient.domain.com,anon=4294967294 /export

Filesystem mounted by Linux (RHEL/Centos 4 and 5) clients:
RHEL/Centos 4 machines upgraded to autofs5.

Following line in /etc/auto.master:
/- /etc/auto.direct --timeout=1200

Following line in /etc/auto.direct:
/path/to/mountpoint -fstype=nfs,noacl,rw,hard,intr,posix
server.domain.com:/export

[Harry Putnam]

Post by Edward Ned Harvey
I don't know if there is something deeper going on here, I'll just start by
saying I'm doing the same thing (but the server is solaris) and I don't have
any problems. This has been in production for quite some time, and used
heavily by many users and various nfs clients. It's rock solid, and
share -F nfs -o
rw=someclient.domain.com,root=someclient.domain.com,anon=4294967294 /export

Is `share' literal... or the name of a zfs_fs like:
/some/shared_zfs_fs? What does the number `4294967294' signifiy.

Post by Edward Ned Harvey
RHEL/Centos 4 machines upgraded to autofs5.
/- /etc/auto.direct --timeout=1200
/path/to/mountpoint -fstype=nfs,noacl,rw,hard,intr,posix
server.domain.com:/export

Egad... I don't even recognize about 90% of that..
So didn't set nothing with `zfs set' regarding sharenfs?

But I'm not a well trained sytem admin... just a homeboy with a home
zfs/nfs/cifs server.

And on the linux hosts, there is no /etc/exports involved? Or does
your /etc/auto.master and /etc/auto.direct do the job /etc/exports
traditionally has done?

[Matthias Pfützner]

Post by Harry Putnam

Post by Edward Ned Harvey
I don't know if there is something deeper going on here, I'll just start by
saying I'm doing the same thing (but the server is solaris) and I don't have
any problems. This has been in production for quite some time, and used
heavily by many users and various nfs clients. It's rock solid, and
share -F nfs -o
rw=someclient.domain.com,root=someclient.domain.com,anon=4294967294 /export

/some/shared_zfs_fs? What does the number `4294967294' signifiy.

If you have ZFS, you don't NEED to put those things into /etc/dfs/dfstab. The
nice thing about ZFS is, it keeps its own "export" list handy.

You need TWO things:

You need to START the NFS server:

svcadm enable svc:/network/nfs/server:default

and then you need to SHARE some directories. If these are located on a ZFS
pool, you can easily share that zpool by:

zfs set sharenfs=on zpoolname

where zpoolname is the name of a zpool...

More details here:

http://blogs.pfuetzner.de/matthias/?p=268

To your questions:

Yes share is literal, because it's the command
For the "number", see "man share_nfs":

anon=uid Set uid to be the effective user ID
of unknown users. By default,
unknown users are given the effec-
tive user ID UID_NOBODY. If uid is
set to -1, access is denied.

So, it should be sufficient to put

share -F nfs /export

into /etc/dfs/dfstab, but only, if that /export is NOT on a zpool!
Otherwise it should be

zfs set sharenfs=on export

assuming, that you called to zpool on which /export lives, export...

Post by Harry Putnam

Post by Edward Ned Harvey
RHEL/Centos 4 machines upgraded to autofs5.
/- /etc/auto.direct --timeout=1200
/path/to/mountpoint -fstype=nfs,noacl,rw,hard,intr,posix
server.domain.com:/export

Egad... I don't even recognize about 90% of that..
So didn't set nothing with `zfs set' regarding sharenfs?

See above, YES, when using ZFS you should do it via zfs set sharenfs. The
wonderful and nice thing is: It's a property of the zpool, so EVEN after a
"zpool export" and an "zpool import" on a different machine, that config is
maintained!

Post by Harry Putnam
But I'm not a well trained sytem admin... just a homeboy with a home
zfs/nfs/cifs server.
And on the linux hosts, there is no /etc/exports involved? Or does
your /etc/auto.master and /etc/auto.direct do the job /etc/exports
traditionally has done?

The Linux host needs to be able to MOUNT the NFS-exported files.

The /etc/auto.master file is using a later "extension" to the NFS system, name
"automount". This only mounts directories, when they are accessed, therefore
"auto-mount".

You could also add the to-be-mounted diretories into /etc/fstab, so that they
are mounted ALWAYS.

But, it seems, you might need to digg a bit around, and get some intorductoriy
infos on

NFS
AUTOMOUNT
and
ZFS

HTH,
Matthias

[Harry Putnam]

Matthias Pfützner <***@Pfuetzner.DE>
writes:


[...]

Post by Matthias Pfützner
svcadm enable svc:/network/nfs/server:default
and then you need to SHARE some directories. If these are located on
zfs set sharenfs=on zpoolname

OK, Edward H.s' post confused me a bit, but as it turns out I have
done the TWO things all along. So I had it right.

I did do some research on this matter a ways back.

And made these settings:

svcs -a|grep nfs
disabled 11:53:11 svc:/network/nfs/cbd:default
online 11:53:36 svc:/network/nfs/status:default
online 11:53:37 svc:/network/nfs/nlockmgr:default
online 11:53:37 svc:/network/nfs/mapid:default
online 11:53:40 svc:/network/nfs/rquota:default
online 11:53:40 svc:/network/nfs/client:default
online 11:53:42 svc:/network/nfs/server:default

zfs get sharenfs z3/projects
NAME PROPERTY VALUE SOURCE
z3/projects sharenfs on local

The problem is that when mounted on linux client with this command:
(one example of 3 shares)

mount -t nfs -o users,exec,dev,suid zfs:/projects /projects

Wheres `zfs' is the name of the server host.

All those detailed were spelled out with some care in the OP.

The problem... also detailed in OP and slightly rewritten here:

The trouble I see is that all files get created with:
nobody:nobody
as UID:GID
even though /projects is set as normal USER:GROUP of a user
on the zfs/nfs server.
(that would be USER=reader GROUP=wheel)

From the remote (linux client), any attempt
to change uid:gid fails, even if done by root on the remote.

So certain things cannot be done. For example a sandbox setup where I
test procmail recipes will not accept the .procmailrc file since its
set:
nobody:nobody
Instead of that USER:GID

And again, the USER:GID exists on both server and client with
the same numeric uid:gid:

osol (server) host:

uname -a
SunOS zfs 5.11 snv_133 i86pc i386 i86pc Solaris

root # ls -lnd /export/home/reader
drwxr-xr-x 60 1000 10 173 2010-03-11 12:13 /export/home/reader

------- --------- ---=--- --------- --------
linux (client) host:

root # uname -a
Linux reader 2.6.33-gentoo #2 SMP Sun Feb 28 22:43:57 CST 2010
i686 Intel(R) Celeron(R) CPU 3.06GHz GenuineIntel GNU/Linux

root # ls -lnd /home/reader/no_bak/procmail_ex
drwxr-xr-x 2 1000 10 48 Mar 11 14:02 /home/reader/no_bak/procmail_ex

Post by Matthias Pfützner
The Linux host needs to be able to MOUNT the NFS-exported files.
The /etc/auto.master file is using a later "extension" to the NFS
system, name "automount". This only mounts directories, when they
are accessed, therefore "auto-mount".
You could also add the to-be-mounted diretories into /etc/fstab, so
that they are mounted ALWAYS.

I do it in the init scripts, with the same result.

Post by Matthias Pfützner
But, it seems, you might need to digg a bit around, and get some intorductoriy
infos on NFS AUTOMOUNT

Well, that is no doubt true...

I didn't use automounting on the linux host but am not having a
problem mounting the shares, with the command shown above.
I do the mount in initscript `local.start' so the shares are always
mounted.

But I am having the problem described above. Even though, far as I
know, I haven't made any changes on either end regarding exporting the
shares or mounting them. But the problems began somewhere a month or
two ago.

I have made at least 2 upgrades with these settings in place on the
server end... and the linux end. Now at b133 on the solaris end.

I've probably made some change and forgot it.. or something similar
but having trouble tracking down the problem.

The settings on both ends are now as shown above. But the problem
with all files being created nobody:nobody persists.

_______________________________________________
opensolaris-discuss mailing list

[Matthias Pfützner]

Harry,

sorry for my first answer, now that you rephrased some of the original post, I
now remember, what your initial problam really was... More inline below...
[...]

Post by Harry Putnam
zfs get sharenfs z3/projects
NAME PROPERTY VALUE SOURCE
z3/projects sharenfs on local
(one example of 3 shares)
mount -t nfs -o users,exec,dev,suid zfs:/projects /projects
Wheres `zfs' is the name of the server host.
All those detailed were spelled out with some care in the OP.
nobody:nobody
as UID:GID
even though /projects is set as normal USER:GROUP of a user
on the zfs/nfs server.
(that would be USER=reader GROUP=wheel)
From the remote (linux client), any attempt
to change uid:gid fails, even if done by root on the remote.

OK, so that ROOT can chnage things, you need to add options to the EXPORT
side (aka, the ZFS server), and then you need to do something like, BECAUSE
NFS was made a bit more secure in versions after .1 (root on the client should
not automatically have root-priviliges on the server seide, therefore that
needs to be sprcified explicitly! And you might need even more options,. more
on that below, the example is just one small from my setup at home):

zfs set sharenfs=root=-***@public.gmane.org pfuetz/smb-share

"man zfs" states at the sharenfs section:

sharenfs=on | off | opts

Controls whether the file system is shared via NFS, and
what options are used. A file system with a"sharenfs"
property of "off" is managed through traditional tools
such as share(1M), unshare(1M), and dfstab(4). Other-
wise, the file system is automatically shared and
unshared with the "zfs share" and "zfs unshare" com-
mands. If the property is set to "on", the share(1M)
command is invoked with no options. Otherwise, the
share(1M) command is invoked with options equivalent to
the contents of this property.

When the "sharenfs" property is changed for a dataset,
the dataset and any children inheriting the property are
re-shared with the new options, only if the property was
previously "off", or if they were shared before the pro-
perty was changed. If the new property is "off", the
file systems are unshared.

You state, that you have the users and groups entries on BOTH (client +
server) done exactly same by hand, so that should be good, still, I would
verify that. And also please check on the ZFS-Server the file:
/etc/nsswitch.conf for the entries for:

passwd
group

They should look like:

passwd: files
group: files

So, with that knowledge, we need to consult "man share_nfs":

The things interesting to you might be the following options:

anon=uid Set uid to be the effective user ID
of unknown users. By default,
unknown users are given the effec-
tive user ID UID_NOBODY. If uid is
set to -1, access is denied.

root=access_list Only root users from the hosts
specified in access_list have root
access. See access_list below. By
default, no host has root access, so
root users are mapped to an
anonymous user ID (see the anon=uid
option described above). Netgroups
can be used if the file system
shared is using UNIX authentication
( AUTH_SYS).

Sadly I don't know, if the Linux host (I don't actively manage Linux hosts, so
I have limited knowhow here!) might also need some additional option, when
mounting the NFS FileSystems...

Post by Harry Putnam
So certain things cannot be done. For example a sandbox setup where I
test procmail recipes will not accept the .procmailrc file since its
nobody:nobody
Instead of that USER:GID
And again, the USER:GID exists on both server and client with
uname -a
SunOS zfs 5.11 snv_133 i86pc i386 i86pc Solaris
root # ls -lnd /export/home/reader
drwxr-xr-x 60 1000 10 173 2010-03-11 12:13 /export/home/reader

Which "ls" command? /usr/gnu/bin/ls, or /usr/bin/ls? Still: Here we see, that
the file had been created by a user with User-ID: 1000 and Group-ID: 10.

What's the output of:

ls -ld /export/home/reader

Does that resolve and list the user-name and group-name?

Post by Harry Putnam
------- --------- ---=--- --------- --------
root # uname -a
Linux reader 2.6.33-gentoo #2 SMP Sun Feb 28 22:43:57 CST 2010
i686 Intel(R) Celeron(R) CPU 3.06GHz GenuineIntel GNU/Linux
root # ls -lnd /home/reader/no_bak/procmail_ex
drwxr-xr-x 2 1000 10 48 Mar 11 14:02 /home/reader/no_bak/procmail_ex

Post by Matthias Pfützner
The Linux host needs to be able to MOUNT the NFS-exported files.
The /etc/auto.master file is using a later "extension" to the NFS
system, name "automount". This only mounts directories, when they
are accessed, therefore "auto-mount".
You could also add the to-be-mounted diretories into /etc/fstab, so
that they are mounted ALWAYS.

I do it in the init scripts, with the same result.

Post by Matthias Pfützner
But, it seems, you might need to digg a bit around, and get some intorductoriy
infos on NFS AUTOMOUNT

Well, that is no doubt true...
I didn't use automounting on the linux host but am not having a
problem mounting the shares, with the command shown above.
I do the mount in initscript `local.start' so the shares are always
mounted.
From the above I only can see, that both, client and server to see the 1000:10

as UID and GID, I don't see, what "names" are associated with these IDs...

Post by Harry Putnam
But I am having the problem described above. Even though, far as I
know, I haven't made any changes on either end regarding exporting the
shares or mounting them. But the problems began somewhere a month or
two ago.
I have made at least 2 upgrades with these settings in place on the
server end... and the linux end. Now at b133 on the solaris end.
I've probably made some change and forgot it.. or something similar
but having trouble tracking down the problem.
The settings on both ends are now as shown above. But the problem
with all files being created nobody:nobody persists.
mount -t nfs -o users,exec,dev,suid zfs:/projects /projects

or

Post by Harry Putnam
zfs get sharenfs z3/projects
NAME PROPERTY VALUE SOURCE
z3/projects sharenfs on local

As mentioned, I would not only set "sharenfs" to on, but add at least the
"root" option, and the "suid" option...

Sadly, again, I don't know, what the "users" option on the Linux Client does,
so I can't say, if that might cause some trouble... Same for the "exec" and
"dev" option...

Matthias

[Harry Putnam]

Post by Matthias Pfützner
Harry,
sorry for my first answer, now that you rephrased some of the
original post, I now remember, what your initial problam really
was... More inline below...

It may not have been or still may not be much of a clear exposition on
my part either...

[...]

Post by Matthias Pfützner
OK, so that ROOT can chnage things, you need to add options to the
EXPORT side (aka, the ZFS server)

[...]
Thanks for that.

[...]

Post by Matthias Pfützner
You state, that you have the users and groups entries on BOTH
(client + server) done exactly same by hand, so that should be good,
still, I would verify that. And also please check on the ZFS-Server
passwd
group
passwd: files
group: files

nisswitch is setup as you've shown

Post by Matthias Pfützner
anon=uid Set uid to be the effective user ID
of unknown users. By default,
unknown users are given the effec-
tive user ID UID_NOBODY. If uid is
set to -1, access is denied.
root=access_list Only root users from the hosts
specified in access_list have root
access. See access_list below. By
default, no host has root access, so
root users are mapped to an
anonymous user ID (see the anon=uid
option described above). Netgroups
can be used if the file system
shared is using UNIX authentication
( AUTH_SYS).

Not really. After more careful reading of share_nfs, mainly as an aid
to working with your posts and info, I'm thinking the defaults should
do just about all I need.

I brought up roots inability on client, to change uid:gid but only
because the defaults appear not to be working. For example:

nosuid

=> By default, clients are allowed to create files on
=> the shared file system with the setuid or setgid
=> mode enabled. Specifying nosuid causes the server
file system to silently ignore any attempt to enable
the setuid or setgid mode bits.

With emphasis on the arrowed lines (not on `nosuid').

Its very possible I'm reading that wrong but it appears to be saying
the client machine users will be able to write files with there own
uid:gid.

That does not occur here. All files are written nobody:nobody

[...]

Post by Matthias Pfützner

Post by Harry Putnam
And again, the USER:GID exists on both server and client with
uname -a
SunOS zfs 5.11 snv_133 i86pc i386 i86pc Solaris
root # ls -lnd /export/home/reader
drwxr-xr-x 60 1000 10 173 2010-03-11 12:13 /export/home/reader

On closer checking I see the above info is erroneous/.

Post by Matthias Pfützner
Which "ls" command? /usr/gnu/bin/ls, or /usr/bin/ls? Still: Here we see, that
the file had been created by a user with User-ID: 1000 and Group-ID: 10.

A default osol install leaves gnu tools first in the path so it was
gnu `ls' I posted.

Post by Matthias Pfützner
ls -ld /export/home/reader
Does that resolve and list the user-name and group-name?

yes, well no.

I've found what may explain some of this... it appears somewhere in
the last few updates on client... my carefully hand edited gid has
disappeared.

There was a point whereas neither users default gid matched but each
belonged to group `wheel', which had been hand edited to match.

So there was a shared gid on both ends. That is no longer the case.
Not sure why.

But even then the share_nfs man page seems to indicate that the client
users will write files to there own gid (there is no mention of
matching gid on both ends)


_______________________________________________
opensolaris-discuss mail

[Matthias Pfützner]

Harry,

all very bizarre... ;-)

Post by Harry Putnam

Post by Matthias Pfützner
Harry,
sorry for my first answer, now that you rephrased some of the
original post, I now remember, what your initial problam really
was... More inline below...

It may not have been or still may not be much of a clear exposition on
my part either...
[...]

Post by Matthias Pfützner
OK, so that ROOT can chnage things, you need to add options to the
EXPORT side (aka, the ZFS server)

[...]
Thanks for that.

You're welcome!

Post by Harry Putnam

Post by Matthias Pfützner
anon=uid Set uid to be the effective user ID
of unknown users. By default,
unknown users are given the effec-
tive user ID UID_NOBODY. If uid is
set to -1, access is denied.
root=access_list Only root users from the hosts
specified in access_list have root
access. See access_list below. By
default, no host has root access, so
root users are mapped to an
anonymous user ID (see the anon=uid
option described above). Netgroups
can be used if the file system
shared is using UNIX authentication
( AUTH_SYS).

Not really. After more careful reading of share_nfs, mainly as an aid
to working with your posts and info, I'm thinking the defaults should
do just about all I need.

Agreed! Accept, possibly, if needed, the "root" option might be handy...

Post by Harry Putnam
I brought up roots inability on client, to change uid:gid but only
nosuid
=> By default, clients are allowed to create files on
=> the shared file system with the setuid or setgid
=> mode enabled. Specifying nosuid causes the server
file system to silently ignore any attempt to enable
the setuid or setgid mode bits.
With emphasis on the arrowed lines (not on `nosuid').

Right!

Post by Harry Putnam
Its very possible I'm reading that wrong but it appears to be saying
the client machine users will be able to write files with there own
uid:gid.

Right!

Post by Harry Putnam
That does not occur here. All files are written nobody:nobody

Strange!

Post by Harry Putnam
[...]

Post by Matthias Pfützner

Post by Harry Putnam
And again, the USER:GID exists on both server and client with
uname -a
SunOS zfs 5.11 snv_133 i86pc i386 i86pc Solaris
root # ls -lnd /export/home/reader
drwxr-xr-x 60 1000 10 173 2010-03-11 12:13 /export/home/reader

On closer checking I see the above info is erroneous/.

Even stranger... ;-)

Post by Harry Putnam

Post by Matthias Pfützner
Which "ls" command? /usr/gnu/bin/ls, or /usr/bin/ls? Still: Here we see, that
the file had been created by a user with User-ID: 1000 and Group-ID: 10.

A default osol install leaves gnu tools first in the path so it was
gnu `ls' I posted.

Right! I only asked, because, if you would be using "sharesmb" also, then
files created via Windows Servers will be nobody:nobody regardless, and all
"access info" is captured in ACLs, and gnu ls simply does not show these
ACLs... You need the Solaris native "ls" to see them...

Post by Harry Putnam

Post by Matthias Pfützner
ls -ld /export/home/reader
Does that resolve and list the user-name and group-name?

yes, well no.
I've found what may explain some of this... it appears somewhere in
the last few updates on client... my carefully hand edited gid has
disappeared.

Strange! I don't know of any automated tool, that would edit either
/etc/passwd or /etc/group...

Post by Harry Putnam
There was a point whereas neither users default gid matched but each
belonged to group `wheel', which had been hand edited to match.
So there was a shared gid on both ends. That is no longer the case.
Not sure why.
But even then the share_nfs man page seems to indicate that the client
users will write files to there own gid (there is no mention of
matching gid on both ends)

You're right again!

Back to NVS v4 vs. v3. I've no idea, on how Linux does define the version, you
mentioned, it's been done in a config file, and that you did set that to be
v3.

Are you sure, that the Linux box does HONOUR that setting? Or might it be the
case, that that is ignored, (perhaps root or daemon or ... can't read it at
boot time)

On Solaris, you would force that in /etc/default/nfs (see "man nfs"), still,
that file needs to be readable at boot time:

[sr1-efra05-04: home/pfuetz] {1310} % ls -al /etc/default/nfs
-rw-r--r-- 1 root root 2870 May 15 2009 /etc/default/nfs
[sr1-efra05-04: home/pfuetz] {1311} %

Still, all very strange!

Matthias

[Harry Putnam]

Post by Matthias Pfützner
Harry,
all very bizarre... ;-)

Probably do to ill informed bumbling on my part.

[...]

Post by Matthias Pfützner

Post by Harry Putnam

Post by Matthias Pfützner
ls -ld /export/home/reader
Does that resolve and list the user-name and group-name?

yes, well no.
I've found what may explain some of this... it appears somewhere in
the last few updates on client... my carefully hand edited gid has
disappeared.

Strange! I don't know of any automated tool, that would edit either
/etc/passwd or /etc/group...

I should have said `reinstall' instead of `upgrade' (on client). There
was a full `from scratch' reinstall, so basic stuff was reset to
default and haven't gotten it all back together yet. Still finding
things I had setup but forgotten about.

Somewhere on these opensolaris lists (mnths ago), I was told that I
needed a user with same uid gid on both server and client for NFS to
work well but I'm not seeing that anywhere in share_nfs.

[...]

Post by Matthias Pfützner
Back to NVS v4 vs. v3. I've no idea, on how Linux does define the
version, you mentioned, it's been done in a config file, and that
you did set that to be v3.

Thanks again for your patience.

I'm not sure either (about nfs on linux) but am checking into that
now.

_______________________________________________
opensolaris-discuss maili

[Matthias Pfützner]

Post by Harry Putnam

Post by Matthias Pfützner
Harry,
all very bizarre... ;-)

Probably do to ill informed bumbling on my part.
[...]

Post by Matthias Pfützner

Post by Harry Putnam

Post by Matthias Pfützner
ls -ld /export/home/reader
Does that resolve and list the user-name and group-name?

yes, well no.
I've found what may explain some of this... it appears somewhere in
the last few updates on client... my carefully hand edited gid has
disappeared.

Strange! I don't know of any automated tool, that would edit either
/etc/passwd or /etc/group...

I should have said `reinstall' instead of `upgrade' (on client). There
was a full `from scratch' reinstall, so basic stuff was reset to
default and haven't gotten it all back together yet. Still finding
things I had setup but forgotten about.
Somewhere on these opensolaris lists (mnths ago), I was told that I
needed a user with same uid gid on both server and client for NFS to
work well but I'm not seeing that anywhere in share_nfs.

You need the SAME entries on Client and Server in "/etc/passwd" and
"/etc/group" so, that it works "correctly" (meaning, the way you want
it). Still, EVEN without the entries on the server, sou should at least see
the correct UIG and GID when doing an ls -al on the SERVER. No need to have
the "strings" in /etc/passwd or /etc/group, the NFS server does not need to
KNOW about those...

share_nfs does not need to and will not show these user ids...

So, if user "willi" on the Linux client hat UID 4711, then on the SERVER you
should see "4711" as the owner of a file, that had been created by "willi" on
a filesystems that had been mounted from the server. The server does not need
to know, that 4711 is "willi", it will still create the file with the ID
4711. That's the basice rule... as long, as the UID is NOT 0 or root...

Post by Harry Putnam
[...]

Post by Matthias Pfützner
Back to NVS v4 vs. v3. I've no idea, on how Linux does define the
version, you mentioned, it's been done in a config file, and that
you did set that to be v3.

Thanks again for your patience.

You're welcome!

Post by Harry Putnam
I'm not sure either (about nfs on linux) but am checking into that
now.

Matthias

[Harry Putnam]

Post by Matthias Pfützner
So, if user "willi" on the Linux client hat UID 4711, then on the SERVER you
should see "4711" as the owner of a file, that had been created by "willi" on
a filesystems that had been mounted from the server. The server does not need
to know, that 4711 is "willi", it will still create the file with the ID
4711. That's the basice rule... as long, as the UID is NOT 0 or root...

Do you have any linux clients to osol nfs server?

If not Matthias, then is there anyone else here who has an osol NFS
server with a linux client, where you can show a simple `ls -l' (on
the client) in a directory created on the mounted nfs share, by a
linux user.

[Edward Ned Harvey]

Post by Harry Putnam
Do you have any linux clients to osol nfs server?
If not Matthias, then is there anyone else here who has an osol NFS
server with a linux client, where you can show a simple `ls -l' (on
the client) in a directory created on the mounted nfs share, by a
linux user.

I still think my original answer is the answer for you. The only difference between your system and mine is that my NFS server is Solaris, and yours is OpenSolaris. Since you said you were confused by my post, let me try to break it down:

On my solaris NFS server, I don't want to export my filesystem to every single IP address on the LAN. I want only specific clients to be able to access the server. In the example below, I'm allowing "someclient" to access the server. These clients must have matching forward and reverse DNS. You could probably set up for exporting NFS to a subnet if you wanted to, but you'd have to read the "man share" command to figure that out. I have exported my NFS filesystem using the following command:
share -F nfs -o rw=someclient.domain.com,root=someclient.domain.com,anon=4294967294 /export

To make the "share" command persistent across reboots, just stick it into /etc/dfs/dfstab after you've run it manually once.

If you like, instead of using "share" and "dfstab" as described above, you can set the sharenfs property on your ZFS filesystem. It has the same effect, according to "man zfs"

If you have a RHEL/Centos 5 client, you have autofs5 installed by default. You can configure automount to automatically mount the NFS server upon attempted access. Here's how:

Edit /etc/auto.master and stick this line in:
/- /etc/auto.direct --timeout=1200

Also edit /etc/auto.direct and stick this line in:
/path/to/mountpoint -fstype=nfs,noacl,rw,hard,intr,posix server.domain.com:/export

If you have a RHEL/Centos 4 client, you have autofs4 installed by default, and autofs4 doesn't support "direct" automount as described above. "Direct" automount is much better than what they could do in autofs4, so it's worth while to remove autofs4 and install autofs5 instead. Then, you can use the same "auto.master" and "auto.direct" as described above.

[Harry Putnam]

Post by Edward Ned Harvey

Post by Harry Putnam
Do you have any linux clients to osol nfs server?
If not Matthias, then is there anyone else here who has an osol NFS
server with a linux client, where you can show a simple `ls -l' (on
the client) in a directory created on the mounted nfs share, by a
linux user.

I still think my original answer is the answer for you. The only
difference between your system and mine is that my NFS server is
Solaris, and yours is OpenSolaris. Since you said you were confused

But yet you were unwilling to show the output of ls -l from the linux
client on a mounted NFS directory.. as I requested, preferring to go
into lots of detail about auto mounting.

Its not the mounting that is a problem for me, and in the light usage
scenario of single user machine, auto mount is not a high
requirement... it just isn't an issue.

Its what I see with unix permissions on the created files.

When your linux users create files on a mounted nfs share, do those
files have that users uid gid, or something else?

Can you show a `ls -l (from linux client) on a mounted NFS share.

[Chris]

Hi Harry, I get files created with UID & GID set by client. See below (some names have been altered to protect the innocent, any inconsistencies are due to that editing)

from mount list:
192.168.0.110:/darkstar/nebulae on /home/chris/osolnfsmount type nfs (rw,nolock,addr=192.168.0.110)

***@plato-gent ~ $ ll osolnfsmount
total 21
drwxr-sr-x 2 root dialout 2 Jan 13 13:41 archive
drwxr-sr-x 3 chris_remote dialout 14 Feb 26 12:55 downloads
drwxr-sr-x 2 root dialout 2 Jan 6 14:31 projects
***@plato-gent ~ $ touch osolnfsmount/test.file
***@plato-gent ~ $ ll osolnfsmount
total 21
drwxr-sr-x 2 root dialout 2 Jan 13 13:41 archive
drwxr-sr-x 3 chris_remote dialout 14 Feb 26 12:55 downloads
drwxr-sr-x 2 root dialout 2 Jan 6 14:31 projects
-rw-r--r-- 1 chris dialout 0 Mar 15 2010 test.file

***@plato-gent ~ $ sudo su chris_remote
Password:

***@plato-gent /home/chris $ touch osolnfsmount/test.2.file
***@plato-gent /home/chris $ ls -l osolnfsmount
total 22
drwxr-sr-x 2 root dialout 2 Jan 13 13:41 archive
drwxr-sr-x 3 chris_remote dialout 14 Feb 26 12:55 downloads
drwxr-sr-x 2 root dialout 2 Jan 6 14:31 projects
-rw-r--r-- 1 chris_remote dialout 0 Mar 15 2010 test.2.file
-rw-r--r-- 1 chris dialout 0 Mar 15 2010 test.file

***@plato-gent /home/chris $ mkdir umask 002
***@plato-gent /home/chris $ mkdir osolnfsmount/test
***@plato-gent /home/chris $ chmod g-s osolnfsmount/test
***@plato-gent /home/chris $ touch osolnfsmount/test/test.file
***@plato-gent /home/chris $ ls -l osolnfsmount/test
total 1
-rw-rw-r-- 1 chris_remote chris_remote 0 Mar 15 2010 test.file

dialout group is GID 20, which happens to be "staff" on OSX.

[Harry Putnam]

Post by Chris
Hi Harry, I get files created with UID & GID set by client. See
below (some names have been altered to protect the innocent, any
inconsistencies are due to that editing)

[...]

Thanks... nothing like some actual data to see how it ends up.

So something is definitely going amiss on my setup.

It wasn't clear how your osol nfs share is set on the server.

Is it just done with `zfs set' like:
`zfs set sharenfs=on pool/path'

Or something more complex?

Post by Chris
from mount list: 192.168.0.110:/darkstar/nebulae on
/home/chris/osolnfsmount type nfs (rw,nolock,addr=192.168.0.110)

That info from your linux client `mount' cmd may tell whats wrong
here. Mine has one extra item in there:

OSOL_SERVER:/pub on /pub type
nfs (rw,users,addr=192.168.0.29,vers=4,clientaddr=192.168.0.2)

Notice the `vers=4' so apparently my linux client is taking a share
that is being offered as nfs=vers3, but trying to mount it as vers4.

Mathias P. asked me that very question, and I wasn't sure how to find
out. I think this may at least show its happening.

I'm curious what your doing here:

***@plato-gent /home/chris $ chmod g-s osolnfsmount/test

Is that turning off set-gid?

Oh, and one more thing to pester you with... can I see the details of
how the client is mounting the nfs share.

I know you've shown the output of `mount' but is there a notation
somewhere that does the job?

And your client is OSX then?... not linux?

[Harry Putnam]

Post by Harry Putnam
That info from your linux client `mount' cmd may tell whats wrong
OSOL_SERVER:/pub on /pub type
nfs (rw,users,addr=192.168.0.29,vers=4,clientaddr=192.168.0.2)
Notice the `vers=4' so apparently my linux client is taking a share
that is being offered as nfs=vers3, but trying to mount it as vers4.
Mathias P. asked me that very question, and I wasn't sure how to find
out. I think this may at least show its happening.

Haaa, I may have solved my problem. Turns out to be some very sloppy
work on my part.

All this time I've been setting:

/etc/default/nfs:
NFS_CLIENT_VERSMAX=3

When I guess I should have been setting:

NFS_SERVER_VERSMAX=3
(and that was commented out)

I think I may have gotten a bit confused there. Now I'm telling the
server only to offer version=3. And guess what? The client users on
linux host can now read/write with there own uid:gid.

Man, I'm really sorry to the list for all my huffing and puffing when
I'm pretty sure I had been claiming I had the right settings in
/etc/default/nfs (but didn't).

[Matthias Pfützner]

Hey, Harry, no problem! Sometimes we all can't see the forest for the
trees... We all assumed, it must have been something like that.

Glad it worked out finally!

Matthias

Post by Harry Putnam

Post by Harry Putnam
That info from your linux client `mount' cmd may tell whats wrong
OSOL_SERVER:/pub on /pub type
nfs (rw,users,addr=192.168.0.29,vers=4,clientaddr=192.168.0.2)
Notice the `vers=4' so apparently my linux client is taking a share
that is being offered as nfs=vers3, but trying to mount it as vers4.
Mathias P. asked me that very question, and I wasn't sure how to find
out. I think this may at least show its happening.

Haaa, I may have solved my problem. Turns out to be some very sloppy
work on my part.
NFS_CLIENT_VERSMAX=3
NFS_SERVER_VERSMAX=3
(and that was commented out)
I think I may have gotten a bit confused there. Now I'm telling the
server only to offer version=3. And guess what? The client users on
linux host can now read/write with there own uid:gid.
Man, I'm really sorry to the list for all my huffing and puffing when
I'm pretty sure I had been claiming I had the right settings in
/etc/default/nfs (but didn't).

[Harry Putnam]

Post by Matthias Pfützner
Hey, Harry, no problem! Sometimes we all can't see the forest for the
trees... We all assumed, it must have been something like that.
Glad it worked out finally!

You put quite a bit into it, thanks for you patience and time.

[Robert Thurlow]

Post by Harry Putnam
Man, I'm really sorry to the list for all my huffing and puffing when
I'm pretty sure I had been claiming I had the right settings in
/etc/default/nfs (but didn't).

This makes a lot more sense. NFSv4 should have worked for
you if you had the client and server both set to the same
NFSv4 domain - if you care to work on this, we can.

Rob T

[Harry Putnam]

Post by Robert Thurlow

Post by Harry Putnam
Man, I'm really sorry to the list for all my huffing and puffing when
I'm pretty sure I had been claiming I had the right settings in
/etc/default/nfs (but didn't).

This makes a lot more sense. NFSv4 should have worked for
you if you had the client and server both set to the same
NFSv4 domain - if you care to work on this, we can.
Rob T

Thanks for the offer. Is there something NFSv4 offers that would make
it worth doing?

This is a home lan so only light usage.

My domain is a fake homeboy domain that will not resolve on any
nameserver (I don't run a local DNS server).

`HOST.local.lan'
192.168.0.NNN

However its there in /etc/hosts, so for internal work, the resolver
looks there first and it seems to fly.

[Robert Thurlow]

Post by Harry Putnam

Post by Robert Thurlow
This makes a lot more sense. NFSv4 should have worked for
you if you had the client and server both set to the same
NFSv4 domain - if you care to work on this, we can.

Thanks for the offer. Is there something NFSv4 offers that would make
it worth doing?

Probably the most tangible difference is the fact that a
modern NFSv4 client will permit you to see child mounts,
which we have sometimes called mirror mounts. With V3,
the only way you can properly handle nested shares on a
server is to list them all in an automounter map; with
V4, they just show up properly. Linux clients and newer
Nevada clients (post snv_77) will do this.

And when I mention NFSv4 domain, it is not necessarily
related to a DNS or NIS domain. They can be different,
and sometimes just are different. This is about how a
client or server converts a UID to a string like
"thurlow-xsfywfwIY+***@public.gmane.org" as V4 needs it, and how the other end
converts it back to a numeric UID. If the domains
don't match, you see "nobody". I don't recall how to
set or see the NFSv4 domain on Linux, but on Solaris you
can see it with "cat /var/run/nfs4_domain" and set it in
/etc/default/nfs.

Rob T

[Matthias Pfützner]

Edward,

Post by Edward Ned Harvey

Post by Harry Putnam
Do you have any linux clients to osol nfs server?
If not Matthias, then is there anyone else here who has an osol NFS
server with a linux client, where you can show a simple `ls -l' (on
the client) in a directory created on the mounted nfs share, by a
linux user.

share -F nfs -o rw=someclient.domain.com,root=someclient.domain.com,anon=4294967294 /export

I'm not sure, the "anon=???" option is needed... That's a bizarre UID to use,
and might be specific to your setup... And the "rw" option is only needed, as
you state, to LIMIT the write option to that specific host...

So, the "standard"

zfs set sharenfs=root=-***@public.gmane.org rpool/export

should really be sufficient...

Post by Edward Ned Harvey
To make the "share" command persistent across reboots, just stick it into /etc/dfs/dfstab after you've run it manually once.

Not needed with ZFS, as that is a property of the ZFS filesystem, and is
persistent, not only across reboots, but even accros "transports" to different
servers, if you unplug the disks and plug them to a different server. Beauty
of ZFS!

Post by Edward Ned Harvey
If you like, instead of using "share" and "dfstab" as described above, you can set the sharenfs property on your ZFS filesystem. It has the same effect, according to "man zfs"
/- /etc/auto.direct --timeout=1200
/path/to/mountpoint -fstype=nfs,noacl,rw,hard,intr,posix server.domain.com:/export
If you have a RHEL/Centos 4 client, you have autofs4 installed by default, and autofs4 doesn't support "direct" automount as described above. "Direct" automount is much better than what they could do in autofs4, so it's worth while to remove autofs4 and install autofs5 instead. Then, you can use the same "auto.master" and "auto.direct" as described above.

Sadly, as mentioned, I don't have a Linux client to test, so, Harry, sorry...

Still, the above commands for the Linux side look plausible to me...

Matthias

[Matthias Pfützner]

Post by Harry Putnam

Post by Matthias Pfützner
So, if user "willi" on the Linux client hat UID 4711, then on the SERVER you
should see "4711" as the owner of a file, that had been created by "willi" on
a filesystems that had been mounted from the server. The server does not need
to know, that 4711 is "willi", it will still create the file with the ID
4711. That's the basice rule... as long, as the UID is NOT 0 or root...

Do you have any linux clients to osol nfs server?

No, sadly not...

Post by Harry Putnam
If not Matthias, then is there anyone else here who has an osol NFS
server with a linux client, where you can show a simple `ls -l' (on
the client) in a directory created on the mounted nfs share, by a
linux user.

Matthias

[Edward Ned Harvey]

Post by Matthias Pfützner
The Linux host needs to be able to MOUNT the NFS-exported files.
The /etc/auto.master file is using a later "extension" to the NFS system, name
"automount". This only mounts directories, when they are accessed, therefore
"auto-mount".
You could also add the to-be-mounted diretories into /etc/fstab, so that they
are mounted ALWAYS.

I've had bad experience setting NFS mounts in /etc/fstab. The problem is:
If the filesystem can't mount for any reason, then the machine doesn't come
up. Unless you set it as a "soft" mount, in which case, the slightest
little network glitch causes clients to lose their minds.

What I wrote in the previous email, about using automount and hard
interruptable NFS mounts was very well thought out and based on years of
commercial deployment of NFS systems. Like I said, it's rock solid if
configured as I described. It's resilient against network failure during
boot, or during operation, yet it's force-interruptable by root if
necessary, which is extremely rare.

[Casper.Dik-UdXhSnd/]

Post by Edward Ned Harvey
If the filesystem can't mount for any reason, then the machine doesn't come
up. Unless you set it as a "soft" mount, in which case, the slightest
little network glitch causes clients to lose their minds.

There is also a "bg" mount option: the mount will continue in the
background when it fails; however, if a NFS mount is always needed, I
suggest to create it in /etc/auto_direct. The mount isn't performed at
boot then but it is delayed until the mountpoint is accessed.

Post by Edward Ned Harvey
What I wrote in the previous email, about using automount and hard
interruptable NFS mounts was very well thought out and based on years of
commercial deployment of NFS systems. Like I said, it's rock solid if
configured as I described. It's resilient against network failure during
boot, or during operation, yet it's force-interruptable by root if
necessary, which is extremely rare.

I agree. automount and not /etc/vfstab.

Casper

[Mike Gerdts]

 A zfs fs set with smb and nfs on, and set chmod g-s (set-gid) with
 a local users uid:gid is being mounted by a remote linux host (and
 windows hosts, but not discussing that here).
 The remote user is the same as the local user in both numeric UID
 and numeric GID
 mount -t nfs -o users,exec,dev,suid
 Any files/directories create by the linux user end up with
 nobody:nobody uid:gid and any attempt to change that from the client
 host fails, even if done as root.

It looks to me like you are using NFSv4 and the NFS mapping domains do
not match. See /etc/default/nfs on OpenSolaris and I don't know what
on Linux.

I'm not sure when this trouble started... its been a while, long
enough to have existed over a couple of builds (b129 b133). But was
not always a problem.
I jumped from 129 to 133 so don't know about builds in between.
I have a zfs_fs .. /projects on zpool z3
this is a hierarchy that is fairly deep but only the top level is zfs.
(Aside:  That is something I intend to change soon)
That is, the whole thing, of course, is zfs, but the lower levels have
been created by whatever remote host was working there.
 z3/projects  sharenfs               on
 z3/projects  sharesmb               name=projects
So both cifs and nfs are turned on making the zfs host both a zfs and
nfs server.
 chmod g-s (set gid) right away.
The remote linux user in this discussion has the same numeric UID and
GID as the local zfs user who is owner of /projects
Later, and more than once by now, I've run this command from the zfs
to get read/write to work when working from windows hosts.
The filesystem is primarily accessed as an nsf mounted filesystem on a
linux (gentoo linux) host.  But is also used over cifs by a couple of
windows hosts.
 mount -t nfs -o users,exec,dev,suid
That has been the case both before having the problem and now.
  nobody:nobody
as UID:GID, even though /projects is set as normal USER:GROUP of a user
on the zfs/nfs server.
From the remote (we only deal with the linux remote here) any attempt
to change uid:gid fails, even if done by root on the remote.
_______________________________________________
opensolaris-discuss mailing list

[Harry Putnam]

Post by Mike Gerdts

 Any files/directories create by the linux user end up with
 nobody:nobody uid:gid and any attempt to change that from the client
 host fails, even if done as root.

It looks to me like you are using NFSv4 and the NFS mapping domains do
not match. See /etc/default/nfs on OpenSolaris and I don't know what
on Linux.

No, that has always been set with:
grep '^[^#].*VERSMAX' /etc/default/nfs
NFS_CLIENT_VERSMAX=3