# General confusion about NFS



## jbo (May 11, 2021)

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:

How does the actual authentication work? Does the NFS client send the UID/GID and a password?
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?
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

```
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

```
V4: /hdd/nfs
/hdd/nfs/myshare -sec=sys 192.168.250.60
```

B: jail's fstab.local

```
192.168.250.61:/myshare /usr/local/mnt/storage nfs rw,vers=4 0 0
```


----------



## Alain De Vos (May 11, 2021)

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 ?


----------



## jbo (May 11, 2021)

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 
	
	



```
www:www
```
 user/group can have r/w access. What needs to happen for this to work?


----------



## SirDice (May 11, 2021)

joel.bodenmann said:


> How does authentication work without Kerberos


There isn't any.



joel.bodenmann said:


> How can I give my jail's `www:www` user/group write access to the share


Set the proper permissions on the shared filesystem.



joel.bodenmann said:


> 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.



joel.bodenmann said:


> How does the actual authentication work? Does the NFS client send the UID/GID and a password?


Without Kerberos there is no authentication. 



joel.bodenmann said:


> 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.



joel.bodenmann said:


> 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.



joel.bodenmann said:


> 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'.


----------



## jbo (May 11, 2021)

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?



SirDice said:


> 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?


----------



## SirDice (May 11, 2021)

joel.bodenmann said:


> 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.


----------



## jbo (May 11, 2021)

SirDice said:


> 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?


----------



## Alain De Vos (May 11, 2021)

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.


----------



## SirDice (May 11, 2021)

joel.bodenmann said:


> 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.


----------



## jbo (May 11, 2021)

Gotcha - Thanks a lot you two!


----------

