[OpenIndiana-discuss] nfs oi server - linux clients

Hugh McIntyre lists at mcintyreweb.com
Tue Sep 16 07:29:14 UTC 2014 

You don't even need NIS or LDAP.  Plain /etc/passwd works fine, either 
by making sure the necessary user/uid mappings and passwd files are the 
same on all systems (if using NFS v2/v3) or not even bothering with the 
uid's matching if using NFSv4.

(Non-matching uid's is kind of the point of the NFSv4 idmap complexity).

Hugh.


On 09/16/2014 12:11 AM, Alex Smith (K4RNT) wrote:
> I used NIS when I was doing this, while I was beta testing Solaris 9 and
> had a Linux client to work with, and that managed to work pretty well,
> given I didn't have any connectivity issues between the hosts.
>
> I know that solution is kinda deprecated, but it's pretty complicated to
> set up LDAP comparatively.
>
> " 'With the first link, the chain is forged. The first speech censured, the
> first thought forbidden, the first freedom denied, chains us all
> irrevocably.' Those words were uttered by Judge Aaron Satie as wisdom and
> warning... The first time any man's freedom is trodden on, we’re all
> damaged." - Jean-Luc Picard, quoting Judge Aaron Satie, Star Trek: TNG
> episode "The Drumhead"
> - Alex Smith
> - Huntsville, Alabama metropolitan area USA
>
> On Tue, Sep 16, 2014 at 1:07 AM, Hugh McIntyre <lists at mcintyreweb.com>
> wrote:
>
>>
>> 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
>>>
>>>
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>

More information about the openindiana-discuss mailing list