[OpenIndiana-discuss] nfs oi server - linux clients

Tue Sep 16 07:11:29 UTC 2014

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
>