If /myvol is a ZFS filesystem, it may be shared via the sharenfs property. Use zfs list to determine the dataset name, then zfs get sharenfs mypool/myfs to query the property.
If this is the case, then you can modify it with:
zfs set sharenfs="sec=sys,rw=server1:server2:server3" mypool/myfs
The most likely reason you are having problems with non-root mounts is the "secure" export option, which is on by default. It disallows mount requests that come in with a source port greater than 1024. On most systems, binding to a port less than 1024 requires root access, so this is a fairly decent way of ensuring the mount was made by root.
The issue, as explained in the README for my NfSpy penetration testing tool, is that the NFS protocol (versions 2, 3, and even 4, without proper configuration) completely trusts the user ID sent in requests from client machines. By limiting requests to only those made by root, you limit your trust to only users on the client machine who have root access. Without this setting (using "insecure" in your exports file), any user can claim to have any UID and access any file on the export.
The reason it is working on Linux is probably because /bin/mount is setuid root:
~$ ls -l /bin/mount
-rwsr-xr-x 1 root root 72188 2011-01-20 13:54 /bin/mount
Just a hunch, but check the permissions on the mount binary on your FreeBSD system. If it is setuid, then you still have a problem, and I don't know what it is. If not, then that would explain what's going on.
Good luck with this, but please consider the security implications of allowing any user on a system to access any file on your server. I recommend using NFS4 with GSS authentication mechanisms instead of the traditional AUTH_SYS flavor.
Best Answer
The Solaris option
llockis the one you want. It means 'local locks'. So the nfs client does use locks, but it's self-contained and doesn't impact other clients.