Matthias Pfützner <matth...@pfuetzner.de>
writes:
[...]
> 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
>
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
> 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.
> 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
opensolaris-discuss@opensolaris.org
