ZFS as non-root errors trying to lock unnecessary etab file.

[aarcane]

when zfs is run as non root via:

chmod /dev/zfs 660;
chgrp zfs /dev/zfs;
gpasswd -a username zfs

zfs and zpool both emit the following error:

exportfs: could not open /var/lib/nfs/.etab.lock for locking: errno 13 (Permission denied)

it then functions as normal, however, is it necessary to lock nfs.etab.lock for this, and other read only commands? I get this error with zfs create, zpool iostat, zpool status, zpool list, and other various commands which have little to no business locking the nfs etab.

[behlendorf]

Yes, this sounds like a bug which just wasn't observed to always running these tools as root. We'll try and limit accessing the etab file to nfs specific commands.

[dajhorn]

I think that this ticket is not-a-bug and the reported behavior is arguably correct.

First, ZoL assumes root privileges in its default configuration. The problem is mitigated by customizing the permissions on the exportfs utility and/or the /var/lib/nfs tree in the same way as the permissions on /dev/zfs must be changed to invoke /sbin/zfs as a non-root user.

Second, the error messages are important for the regular configuration, but otherwise cosmetic.

Third, exportfs itself does not accommodate the desired behavior, so consider filing a bug against the NFS package. It isn't immediately obvious why they do that, so breaking the lock from the calling process could be a bad thing.

This ticket might be a bug if ZoL implements delegations, per issue #362, or gets packaging that provisions a system group for zfs, like on Solaris.

[behlendorf]

I'm going to defer this work until we have delegations properly working.

[pdf]

FWIW, I can't reproduce. With confirmation, I believe this can be closed.

[behlendorf]

This was resolved by commit 4dad7d9. Closing.