General confusion about NFS

jbo@

Developer
I am generally confused about how to use NFSv4 properly.
My situation is rather simple: An application server and a storage server. The application sever has several jails some of which are supposed to get access to an NFS share on the storage server. The two servers are connected over a 1:1 10 Gbps ethernet link. The idea is to create one NFS share per jail that needs some storage. The storage server uses ZFS but not the sharenfs property.

I fail to understand two things:
  • How does authentication work without Kerberos
  • How can I give my jail's www:www user/group write access to the share
I want to use NFSv4 without kerberos. If I understood correctly, this means that I have to setup the user account that wants to access the NFS share on the NFS server as a local user. NFSv4 will then include the UID/GID (maybe as strings?) in the RPC request.

Questions:
  1. How does the actual authentication work? Does the NFS client send the UID/GID and a password?
  2. If it's correct that the NFS server needs to have the same local user as the client, does this mean that I need to setup the user account on the server for the user on the client which mounts the share or for the user which is supposed to have rw access?
  3. How can I give my jail's `www:www` user/group rw access to the share which gets mounted by another user (presumable the jail host's root user which issues the mount call`.
I managed to set everything up in a way that makes the files on the NFS share show up in the jail's /usr/local/mnt/storage (see config below). However, I am either unable to create new files on there (when not using -maproot) or I see the existing files as nobody:nogroup if using -maproot).

Could somebody try to shed some general light on this?

Here's my current setup:
  • Host A: NFSv4 server running FreeBSD 13.0-RELEASE has 192.168.250.61
  • Host B: jail host using FreeBSD 13.0-RELEASE and CBSD (for jail management) has 192.168.250.60
A: /etc/rc.conf
Code:
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsv4_server_only="YES"
nfsuserd_enable="YES"
nfsuserd_flags="-manage-gids"
mountd_enable="YES"

A: /etc/exports
Code:
V4: /hdd/nfs
/hdd/nfs/myshare -sec=sys 192.168.250.60

B: jail's fstab.local
Code:
192.168.250.61:/myshare /usr/local/mnt/storage nfs rw,vers=4 0 0
 
NFS is in itself an insecure protocol. But you can do secure authentication with a kerberos server as far as i understand.
Did you setup a Kerberos server ?
 
No, I did not setup kerberos. As explicitly stated I don't want to use kerberos.
As the two hosts are directly connected over an ethernet link and the shares are not available from other interface I am okay with this.

However, I am still facing the problem that I don't know how to get this working so my jail's
Code:
www:www
user/group can have r/w access. What needs to happen for this to work?
 
How does authentication work without Kerberos
There isn't any.

How can I give my jail's www:www user/group write access to the share
Set the proper permissions on the shared filesystem.

If I understood correctly, this means that I have to setup the user account that wants to access the NFS share on the NFS server as a local user. NFSv4 will then include the UID/GID (maybe as strings?) in the RPC request.
NFSv4 actually 'translates' the username, NFSv3 was only based on UID/GID so you had to make sure those were the same. NFSv4 uses nfsuserd(8) to translate the UID/GID of "userA" on one machine to the UID/GID of "userA" of the other. So now you just need to make sure the usernames are the same and the actual UID/GID doesn't matter anymore.

How does the actual authentication work? Does the NFS client send the UID/GID and a password?
Without Kerberos there is no authentication.

If it's correct that the NFS server needs to have the same local user as the client, does this mean that I need to setup the user account on the server for the user on the client which mounts the share or for the user which is supposed to have rw access?
Yes.

How can I give my jail's `www:www` user/group rw access to the share which gets mounted by another user (presumable the jail host's root user which issues the mount call`.
It's not the user that does the mounting, it's the system that does the mounting. That users only accesses it.

However, I am either unable to create new files on there (when not using -maproot) or I see the existing files as nobody:nogroup if using -maproot).
Don't use -maproot unless you need to write files as root that also need to be owned by root. But this is a security issue, so avoid it as much as possible.


On system A set the permissions on /hdd/nfs/myshare to 775 and ownership to www:www for example. After you mounted the filesystem on system B you might need to set the permissions on /usr/local/mnt/storage too. If the permissions are 775 and ownership is www:www then anyone that's a member of the www group should be able to write there, including the www user itself. Note that for web servers the www user only has to have read access in that directory, letting the web server write to that directory opens up the possibility of a hacked server being able to modify those files (what you typically don't want to happen). Sometimes the www user does need write access, usually for cache or upload directories, then set the write access on those directories specifically.

So permissions like 775 and root:webdeveloper is typically enough. Anyone in the webdeveloper group should be able to write there and the www user has read access through 'others'.
 
Thank you for your responses :)

I might need a bit more information on the particular matter of giving the www:www jail user rw access to the share. Do I need to create the www user on the NFS host? As in: the UID/GID check that is being performed, is that in respect of the user which should have access to the share - nothing related to the mounting as you pointed out this is done by "the system" and not a user?

Set the proper permissions on the shared filesystem.
Are we talking about the underlying FS that is being exported by NFS - in my case the /hdd/nfs/myshare ZFS dataset? Or is this an NFS level permission problem?
 
Are we talking about the underlying FS that is being exported by NFS - in my case the /hdd/nfs/myshare ZFS dataset? Or is this an NFS level permission problem?
It's a bit of both, permissions should be set correctly on both the server and client side.
 
It's a bit of both, permissions should be set correctly on both the server and client side.
I'm sorry Sir, I really don't mean to be a pain in the butt but this is really something I am not understanding properly: For which user does this apply (on the server)? The user that needs access to the share? In my case this would be the jail's www user.

I am starting to wonder whether it would be a better to just have an NFS share for the entire application server, mount that on the jails host and then use nullfs to give each jail access to a sub-directory. Does that sound like a decent thing to do?
 
I was confused myself. It's only IP address that counts or hostname for identifying clients.
Login can happen with username and password.
auth_sys is based on UID & GID.
 
I'm sorry Sir, I really don't mean to be a pain in the butt but this is really something I am not understanding properly: For which user does this apply (on the server)? The user that needs access to the share?
The first time you mount an NFS share on the "client" the directory is likely going to have root:wheel as the owner and 755 permissions. So you'll need to adjust those permissions for your situation. Those settings will be "remembered" the next time you mount that share. So from a client system's point of view, just look as mounting an NFS share the same as adding another physical disk with a filesystem. Then you also need to adjust the permissions of that newly mounted filesystem. From the system's point of view it's irrelevant if that filesystem happens to be an NFS share or a partition on a locally attached physical disk.
 
Back
Top