I've been helping davecasa try to run this down. First, the NFS stuff. Both the freenas box and the ubuntu hosts get their uses from the same LDAP database, and this was verified by checking "getent passwd" on all machines involved. Setting an owner to an LDAP user by running chmod locally on the FreeNAS box works fine and propagates just fine to clients using NFSv3. I found a post somewhere about some flavors of *NIX refusing to let users give away files, even if they own them; some sort of security corner-case involving quotas. Not sure if that's true or not, but it would certainly explain the observed behavior. Either way, we want to be able to write root-owned files from the clients.
By default, it seems, root on the client machines is mapped to an invalid user (actually displays UID 4294967294) as a security measure. I guess this is standard NFS behavior; with a Linux NFS server, one would fix it by specifying "no_root_squash" on the NFS exports file. In BSD, googling seems to suggest we use maproot=root and the same for wheel. However, specifying that in the web GUI returns "invalid user" for root and "invalid group" for wheel. Both root and wheel are locally-defined. Specifying a valid LDAP user seems to fail silently.
So now we arrive at an underlying LDAP issue. At least part of the issue is that the FreeNAS manage.py code only ever talks to the LDAP server on port 389, even though we have required SSL (or TLS) on the ldaps port (636). There's clearly code to switch the port over to the ldaps port (see FreeNAS_LDAP_Directory.__init__), but the log messages recorded still show common.freenasldap trying to contact the correct server on port 389. Excerpt from debug.log, with LDAP server URL redacted:
[root@freenas] /var/log# grep -i ldap debug.log
<snip>
Jan 18 14:22:19 freenas manage.py: [common.freenasldap:251] FreeNAS_LDAP_Directory.open: uri = ldaps://correcthost.redacted.edu:389
Jan 18 14:22:19 freenas manage.py: [common.freenasldap:254] FreeNAS_LDAP_Directory.open: initialized
Jan 18 14:22:19 freenas manage.py: [common.freenasldap:291] FreeNAS_LDAP_Directory.open: trying to bind
Jan 18 14:22:19 freenas manage.py: [common.freenasldap:209] FreeNAS_LDAP_Directory.open: (authenticated bind) trying to bind to correcthost.redacted.edu:389
The protocol was correct, the only issue seems to be the port. We're running FreeNAS 9.3 with an 8 Dec build date querying against a slapd server running on ubuntu 14.04. Editing /etc/directoryservice/LDAP/config to set the port number correctly lets the OS talk to the LDAP server, as may be verified with "getent passwd" and similar. The LDAP server also serves an apache setup and 2 Ubuntu 12.04 hosts, so it seems to be working more or less fine.
This issue seems to be "further to the topics discussed here:"
https://bugs.freenas.org/issues/7421
Adding a "port" field to the LDAP page might also be a good idea, especially for folks running non-standard setups.
If this is just a simple little python bug, we'd be happy to try to run it down and come up with a specific fix for this little issue, but I'd hate to run around duping somebody's efforts. Especially if we're just going to find more systemic issues. Thoughts?
Thanks! FreeNAS is already proving pretty shiny as a ZFS delivery system.