Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 May 2014 18:05:21 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        "Marty J. Sullivan" <marty.sullivan@cornell.edu>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: nfsv4 server with ACL's for RHEL clients
Message-ID:  <539317876.4358954.1399500321729.JavaMail.root@uoguelph.ca>
In-Reply-To: <89bb0dc035824b8f9c05da1615b030aa@BY2PR04MB096.namprd04.prod.outlook.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Marty J. Sullivan wrote:
> I am testing FreeBSD 10.0 for use as a ZFS storage server. Currently
> I am testing Active Directory integration and serving files via AFP,
> SMB/CIFS, and NFSv4. My current production environment contains
> mostly Linux (CentOS/RHEL) and OSX machines all bound to the same
> Active Directory domain.
> 
> So far, I have gotten the Active Directory authentication set up via
> Samba4.1+Winbind and it is working nicely as are the related CIFS
> shares. I also have AFP set up via afpd and it is also working
> great. ACL's a treated the same way as they are on other systems in
> my production environment.
> 
> Where I am having trouble is getting NFSv4 to work with ACL's. First
> off, I am very used to NFS on Linux and so the /etc/exports syntax
> is almost certainly what is causing my troubles. On RHEL, here is
> what my /etc/exports might look like:
> 
>   /data   mycomputer.mydomain.com(rw,no_root_squash)
> 
> And I start mountd with the option "--manage-gids" so that gid's are
> not managed by the client (since they would then be limited to 16
> groups). This works great and ACL's work fine across all of my Linux
> systems.
> 
> 
> 
> On FreeBSD, this is what I have for my /etc/exports at the current
> time:
> 
>   V4: / mycomputer.mydomain.com
>   /data -maproot=root -network xxx.xxx.xxx.xxx -mask xxx.xxx.xxx.xxx
> 
> Now, I've read many posts about this syntax and I can't seem to find
> a straight answer as to whether the "/data" entry below the "V4:"
> entry applies to NFSv4 or NFSv3.
The line applies to both. However you have not exported "/". The "V4:"
line just defines where the NFSv4 root is, it does not export any file
system. If you change the above to:
V4: /data -network xxx.xxx.xxx.xxx -mask xxx.xxx.xxx.xxx
/data -maproot=root -network xxx.xxx.xxx.xxx -mask xxx.xxx.xxx.xxx

Then "/data" is mounted via:
# mount -t nfs -o vers=4 <server>:/ /mnt

> Either way, it doesn't really work.
> I've tried tinkering with these exports in many permutations and I
> just can't get it to work. Most of the time the machine will be
> denied access (due to bad exports file). Other times, it will mount
> but will just say "Input/Output error" when I try to read from the
> share. And finally, sometimes I can mount the share on an RHEL
> system, but when I use nfs4_getfacl, it says that the operation is
> not supported by the server.
> 
At one time, the Linux client tried to munge a POSIX draft ACL into
an NFSv4 ACL. I have no idea if nfs4_getfacl suports native NFSv4
(aka Windows style) ACLs.

> My other concern is, even if I get the ACL's to work, mountd on the
> FreeBSD server doesn't have a similar option to --manage-gids so the
> NFS group limitation will apply to the RHEL clients. I've read about
> gssd and kerberizing, but I don't feel like that's possible on the
> RHEL clients. So how do I solve this problem??
> 
There is nothing like "--manage-gids" on FreeBSD. If you have users
in more than 16 groups, the NFS server will only see the first 16
(or 17 if the Linux client doesn't duplicate the gid in the gid list
 for the AUTH_SYS authenticator).
The only way to avoid this would be using Kerberos instead of AUTH_SYS.

rick

> Any help with this is appreciated.
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539317876.4358954.1399500321729.JavaMail.root>