[OpenIndiana-discuss] nfs oi server - linux clients

[Hugh McIntyre]

Hi Harry,

It's possible you have somehow mounted the filesystem locally with 
noexec (unlikely, but you can check with "mount | grep /projects/dv" and 
make sure noexec is not in the options).

But at a guess, it's more likely you may have the wrong username mapping 
since NFSv4 may need configuration for this.

The easiest way to check the user mapping is:

1. Create a directory on the server with permissions 777 (wide open)
2. On the client, "touch somefile"
3. Then check on both the server and client which user/group the file is 
created as.  Do not proceed until the usernames match.

If you have a user/group mismatch, then the fix depends on which version 
of NFS you are running.  In "traditional" NFS (v3 or v2), the client 
just sends the numeric uid/gid over the wire, and the assumption is that 
the server has the same passwd/group file mapping.  In your case though 
you seem to be using nfs4, which works differently.

In NFS v4 (the new default) the configuration is more complex.  NFSv4 
uses names instead of numbers (so you don't need the same UID on all 
boxes), but the complexity is that there's a "nfsmapid" service on 
Solaris that translates from NFS username to local uid/names.  This 
relies on a nfsmapid_domain and if this is misconfigured, you get access 
problems.  Similarly, rpc.idmapd.conf on Linux.

For the Solaris/Illumos end, Oracle has some info at 
http://docs.oracle.com/cd/E23824_01/html/821-1462/nfsmapid-1m.html but 
the summary for the Solaris end is:

1. You can specify the NFSMAPID_DOMAIN parameter in nfs(4) or using 
sharectl.
2. Or specify the _nfsv4idmapdomain DNS resource record.  This is what I 
do since I have a local DNS server and then it works for all hosts.
3. Or if neither of these, Solaris will attempt to auto-determine the 
domain based on the domainname command, which may or may not give 
correct results.

Meanwhile on Linux, the daemon (for client and server) is rpc.idmapd. 
In particular, you can configure the domain in /etc/idmapd.conf:

	# default is FQDN minus hostname
	Domain = local.lan

You just have to make sure the client and server use the same domain. 
If not, requests will probably be treated as user=nobody and you may get 
permission errors.

As you can see, in theory if everyone uses a default of FQDN minus 
hostname you may get correct operation by default.  But this does not 
always work, so might be your issue.

Hugh.


On 09/15/2014 03:46 PM, Harry Putnam wrote:
> I need a current modern walk thru of what it takes to setup nfs
> serving, so that the clients' users are able to access rw and run
> scripts or binaries.
>
> First a quite description of the situation:
> First and formost I am a terrrible green horn.  I've rarely used nfs.
> And never with solaris as server
>
>    oi server on home lan of a few linux hosts and a few windows hosts.
>    Very small network with really only single user usage of the nfs
>    shares.
>
>    Home lan is in 10.0.0.0/24 network (All hosts concerned
>    here).
>
> Googling can lead to major confusion since the direction are a bit
> different (as I understand it) from earlier versions of solaris/oi and
> now.
>
> As I understand it, it should take no more than zfs set sharenfs=on.
> I guess the old export list etc isn't necessary.
>
> I have set ' zfs set sharenfs=on ' on this share.
>
> But using that theory, what I'm ending up with on the client side:
> Is a mounted share that will not allow my user to execute anything.
> Where as rw and delete work fine.
>
> When I mount an nfs share on linux (Debian jessie) the mount is setup
> in /etc/fstab like so:
>
> # [HP 140814_122407  NFS MOUNTS
>    # 2x.local.lan:/rpub/dv_pub /nfs/rpub-dv-pub  nfs4   rw     0     0
>    2x.local.lan:/projects/dv /nfs/projects/dv  nfs4   rw,user,exec     0     0
> # ]
>
> You can see the two versions I've tried on different shares.
>
> I've used both of the syntax shown above on the current uncommented
> share with the same result as stated above... no execution.
>
> I can read/write/delete but cannot execute a script.
>
> a simple perl script:
>
> cat p.pl:
>    #!/usr/local/bin/perl
>
>    use strict;
>    use warnings;
>
>    print "hello world\n";
>
> set with chmod 755
>
> And yes... the perl binary referenced is in place and working.
>
> Gets this error output:
>
> ./p.pl
> bash: ./p.pl: Permission denied
>
> And the permissions + owner:group look weird.
>
> OK, where to from here?
>
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>