# nfs server within jail



## andrewm659 (Apr 24, 2017)

Is this possible?  I have seen older threads stating this is not possible.  But I think it might have to do with older versions...

do I need to explicitly disable nfs and rpc on the host?


----------



## SirDice (Apr 28, 2017)

andrewm659 said:


> I have seen older threads stating this is not possible. But I think it might have to do with older versions...


Yeah, older versions of rpcbind(8)/mountd(8) couldn't be bound to a specific IP address. But this should now be possible. Never tried it in a jail though but all the required utilities are now able to bind specific IP addresses so in theory it _should_ work.


----------



## andrewm659 (May 2, 2017)

I think the key phrase here is "IN THEORY" 

I'll continue to research.

Thank you!


----------



## SirDice (May 2, 2017)

andrewm659 said:


> I think the key phrase here is "IN THEORY"


Yeah, I've never done it myself so I can only speculate. Just make sure any NFS related services on the host are specifically bound to the host's IP address. Typically these services run on '*' (all addresses) and thus may catch requests that are actually targeted at the jail's IP addresses. This will cause all sorts of weird and wonderful conflicts.


----------



## ANOKNUSA (May 2, 2017)

I honestly can't see any benefit to running NFS inside a jail. Accessing NFS over the Internet is a bad idea no matter how you do it. If you're using NFSv2 NFSv3 there's no authentication or encryption, hence no real security no matter where the source is. If you're using NFSv3  NFSv4 you have Kerberos authentication, which makes the jail superfluous.. The jail just adds extra hassle.

EDIT: Fixed NFS version numbers.


----------



## andrewm659 (May 2, 2017)

I was hoping to export my rancid directory from the jail.


----------



## SirDice (May 2, 2017)

ANOKNUSA said:


> If you're using NFSv2 there's no authentication or encryption, hence no real security no matter where the source is. If you're using NFSv3 you have Kerberos authentication, which makes the jail superfluous..


NFSv3 has no authentication, NFSv4 can use Kerberos. NFSv2 is pretty much dead and deprecated.


----------



## ANOKNUSA (May 2, 2017)

SirDice said:


> NFSv3 has no authentication, NFSv4 can use Kerberos. NFSv2 is pretty much dead and deprecated.



My mistake. I fixed my post.



andrewm659 said:


> I was hoping to export my rancid directory from the jail.



You can use nullfs(5) to mount a directory on the host inside the jail. Just create an fstab file for the mountpoint with the name /etc/fstab.[jail_name], similar to this:


```
/path/to/RANCID/data/directory /path/to/RANCID/mountpoint/in/jail  nullfs   rw             0       0
```

Then add a line to /etc/jail.conf to mount the directory when the jail is started.:

```
...
mount.fstab = /etc/fstab.[jail_name];
...
```

You could then export the directory over NFS from the host system while also having it mounted in the jail.


----------



## jgreco (Nov 5, 2017)

SirDice said:


> Yeah, I've never done it myself so I can only speculate. Just make sure any NFS related services on the host are specifically bound to the host's IP address. Typically these services run on '*' (all addresses) and thus may catch requests that are actually targeted at the jail's IP addresses. This will cause all sorts of weird and wonderful conflicts.



This usually works with userland processes, but in the case of NFS and jails, there are some unresolved issues because it is a kernel service and there are some problems, particularly with NFS locking, where the kernel doesn't obey binding to a specific interface, instead sourcing it as it desires, and there are some lesser issues as well.



ANOKNUSA said:


> I honestly can't see any benefit to running NFS inside a jail. Accessing NFS over the Internet is a bad idea no matter how you do it. If you're using NFSv2 NFSv3 there's no authentication or encryption, hence no real security no matter where the source is. If you're using NFSv3  NFSv4 you have Kerberos authentication, which makes the jail superfluous.. The jail just adds extra hassle.



I honestly don't understand why you've equated running NFS inside a jail to accessing NFS over the Internet.  For those of us engineering resilient networks and services, jails are a convenient abstraction.  Bind a jail to a loopback interface and inject it into the routing environment.  If you're doing things like this, you really don't want the kernel deciding to use any of the server's ethernet interfaces as a traffic source.  If I can use a jail, I can let the routing protocol handle things like link failure, traffic balancing, and other network management issues (especially between sites) with an IGP such as OSPF.   As it stands, FreeBSD can't do this correctly, which is unfortunate, but I understand that most people don't pursue the sorts of redundant network designs that I've been doing for several decades, and therefore there isn't really a lot of awareness of the deficiency here.


----------



## bds (Nov 16, 2017)

# cat /usr/ports/net/unfs3/pkg-descr
UNFS3 is a user-space implementation of the NFSv3 server specification. It
provides a daemon for the MOUNT and NFS protocols, which are used by NFS
clients for accessing files on the server.
Since it runs in user-space, you can use it in a jail.

WWW: http://unfs3.sourceforge.net/​
I've not used it for a while, but when I did it worked well enough in a jail.


----------



## jgreco (Nov 16, 2017)

Yeah, that's probably an option.  I think there are some things to look at in terms of people who were working on porting Ganesha and Gluster as well.  The downside is that it is user-space stuff, but of course we do lots of silly CPU-burning stuff these days and it all sort of works even so.  ;-)


----------



## _jo_ku (May 24, 2020)

Has anyone a working configuration for a nfs server within a jail?

I've set up an iocage jail and enabled VNET on it to have a full virtual network stack. I can share files via samba without any trouble. I now wanted to share some data via nfs, but can't get this to work.

The nfs daemon doesn't even start up:


```
root@sambaserver:~ # service nfsd start
sysctl: vfs.nfsd.nfs_privport=0: Operation not permitted
NFSv4 is disabled
sysctl: vfs.nfsd.server_max_nfsvers=3: Operation not permitted
Starting nfsd.
```

`service nfsd status` tells me `nfsd is not running` afterwards.

`/var/log/messages` shows the following output:

```
May 24 11:43:15 sambaserver mountd[6764]: Can't delete exports for V4:
May 24 11:43:15 sambaserver mountd[6764]: can't delete exports for /media/nasdata: Operation not permitted
May 24 11:43:15 sambaserver mountd[6764]: can't change attributes for /media/nasdata:
May 24 11:43:15 sambaserver mountd[6764]: bad exports list line '/media/nasdata 192.168.178.22'
May 24 11:43:19 sambaserver nfsd[6787]: Can't read stable storage file: Operation not permitted
```

`/etc/rc.conf` looks like this (I get the same output when I don't bind anything to the jails IP at all):

```
rpcbind_enable="YES"
rpcbind_flags="-h 192.168.178.122"
rpc_lockd_enable="YES"
rpc_lockd_flags="-h 192.168.178.122"
rpc_statd_enable="YES"
rpc_statd_flags="-h 192.168.178.122"
mountd_enable="YES"
mountd_flags="-h 192.168.178.122"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4 -h 192.168.178.122"

#NOTE: SAME RESULT WITH THIS CONFIG from https://www.freebsd.org/doc/handbook/network-nfs.html:
#rpcbind_enable="YES"
#nfs_server_enable="YES"
#mountd_enable="YES"
#mountd_flags="-r"
```

`/etc/exports` is fairly simple:

```
root@sambaserver:~ # cat /etc/exports 
/media/nasdata 192.168.178.22
```


----------

