Unable to chown in mounted FreeNAS volume from client machines

[davecasa]

We're running FreeNAS 9.3, grabbing users and groups through LDAP. We have Ubuntu 12.04 client machines that authenticate through the same LDAP server. The FreeNAS server hosts a single large volume which we want to mount on each of the client machines and use it as if it is a local volume, with consistent users, permissions, etc.

From the Ubuntu clients, we're unable to chown anything on the mounted volume. sudo chown fails with operation not permitted. When run in the FreeNAS shell as root, it succeeds. Google results suggest this can be solved by setting a maproot user, but we're unable to set maproot to any local user (such as root:wheel). We can set maproot to a user from LDAP, but it doesn't appear to do anything.

Any thoughts?

 

[SweetAndLow]

Well you can't chown a file unless you own it. On the client does the file appear to be owned by the user trying to chown? I bet it doesn't and you need to fix up your mount options or uids on the client. Is the client using LDAP also or are they just local users?

 

[cyberjock]

I just had a 66 hour scrub (the longest by about 50%). I am running a plex jail (latest version of plexpass available by pkg-ng 0.9.11.7.803). My server disk usage is all over because of the scrub and streaming, so I can't give an accurate review of the reporting info. BUT, I can say that my scrub was taking much longer because the scrub was constantly being interrupted. So I may have been hit by this. Time will tell...

 

[blockserver]

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.

 

[blockserver]

Ok, we've pretty much finished debugging the NFS side of this. For the sake of posterity:

The issue may be resolved by setting maproot=root and the same for wheel. The issue was that the failure of the underlying LDAP connection due to the port issue prevented any user resolution and broke the GUI's user validation for local users as well as LDAP users. Whether that constitutes a bug may be left as an exercise for the reader. We'll re-open the LDAP issue in a more appropriate thread.