@Stefan_Lasiewski the 10.42.x.x address is a container that uses the rancher managed network. If you were to be less restrictive with the permissions on the server, say allowing mounting from any ip address, is there any change?
I’m not not sure that would work. The NFS server can’t see the traffic from 10.42.x.y, so I don’t think allowing it would be valid.
I’d prefer not to open our NFS server to an ephemeral, private range of 10.42.0.0/16 addresses.
I’ve in trouble also with the nfs-storage approach and an external NFS server.
In fact in this approach the nfs-client is behind a NAT, so the NAT (rancher-host) rewrite the source port > 1024 which could be not authorized from the NFS server side.
Maybe if you put the flag “insecure” on the export it’ll work ?
@RenaudManda , you might be on to something regarding NAT and rewriting the
source port > 1024. I’m not sure if our NFS service has that as an option,
but I’ll check.
-= Stefan
@aemneina nfs v4 on the server with this exports file:
root@nas:~# cat /etc/exports
/volumeUSB1/usbshare 192.168.0.0/16(rw,async,no_wdelay,crossmnt,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)
When I’m getting Invalid argument errors while trying to chown the file from the container the server’s syslog reports “cannot map user 1000@ag.local” The latter is my nfs4 domain name.
curious what folder you’re bind mounting in the container?
/volumeUSB1/usbshare/rancher-storages/test. I set up test volume in rancher-nfs and then use it as -v test:/test --volume-driver rancher-nfs
Just to close up on on the NFSv3 discussion here, it appears that RancherLabs doesn’t support NFSv3, according to https://github.com/rancher/rancher/issues/7080#issuecomment-269823485 .
NFSv4 is required.
@Stefan_Lasiewski do you know which minor version of nfsv4 is supported ? Indeed after a long discussion with my ISP whose providing my NAS-HA using NFS even if we use nfsv4 we have to use nfs v4.1 to have optimal performance due to a callback channel delegation from the server to the client for the locking subsystem.
Moreover I’ve test the new rancher-nfs with a NFS v4 server but rancher (or the image container I don’t know yet) have an issue with the message “Cannot do chown on /…”. Is the nfs-server have to support chown operation to work properly with rancher-nfs or it’s just an issue with the container I try to use ? (FYI I tested with confluence from the community catalogue)
Ok, now what’s the correct setup in order to have things working (correct ID mapping, etc.)?
@renaudManda Sorry, no I don’t have that information. All I know is that Rancher doesn’t support NFSv3, according to the Rancher code on Github and the comments in that ticket. I don’t have a working Rancher NFSv4 server to test.
One could test by setting up another container running NFS, and have a safe place to test out various options.
Hi all
From my experiences, i was not able to use rancher-nfs on any “dockerized NFSv4 server In kernel mode” i get always an error mount.nfs mount(2) access by the server.
After many tries, i discover nfs-ganesha.
This is a "User Space NFSv3,v4,v4.1 … Implementation "
And finally i successfully tested the image “mitcdh/nfs-ganesha” as dockerized NFSv4 into the rancher IPSec network (10.42.0.0/16)
Hope it will Help you
Hi,
For my side I’ve just delegate the nfs par on the host 
Is your volume available in the storage space of rancher ? (and docker) ?
Is your nfs server inside or outside of the 10.42.0.0/16 range ? Because I’ve lot of documentation about lack of support for NFSv3 with NAT transversal (without using special flag on server side) and poor performance for NFSv4 (before 4.1 protocol).
I’m interested by your feedback specially if you gone in production 
Renaud
Just a heads up to anyone also struggling with NFSv4. I was running Ubuntu hosts and I kept running into user/group issues when rancher-nfs mounted. The containers were seeing nobody:nobody. I had to remove the package ‘nfs-common’ from the host and then perform an autoremove which removed ‘libnfsidmap2’. Looks like ‘libnfsidmap2’ causes issues when the containers try to mount the nfs export.
Hi,
I’m still new to this and I’m trying to setup rancher-nfs on rancher. And still can’t get it working.There’s barely any documentation to follow.
Here’s the few things that I did:
- Launch Rancher Nfs via catalog.
My configuration:
image: rancher/storage-nfs:v0.6.0
environment:
MOUNT_DIR: /
MOUNT_OPTS: nfsvers=4
NFS_SERVER: 192.168.99.102 //(hostsip address)
- Added a service that uses rancher-nfs as volume driver.
version: '2'
volumes:
test_volume:
external: true
driver: rancher-nfs
services:
efsadmin:
image: ubuntu:14.04.3
stdin_open: true
volumes:
- test_volume:/data
tty: true
command:
- bash
labels:
io.rancher.container.pull_image: always
io.rancher.scheduler.global: 'true'
Still getting the following errors:
5/5/2017 4:16:42 PMtime="2017-05-05T08:16:42Z" level=info msg=Running
5/5/2017 4:16:42 PMtime="2017-05-05T08:16:42Z" level=info msg=Starting
5/5/2017 4:16:42 PMtime="2017-05-05T08:16:42Z" level=info msg="Running on host rancher(1h3) with driver rancher-nfs(1sd8)"
5/5/2017 4:16:42 PMtime="2017-05-05T08:16:42Z" level=info msg="Starting plugin for rancher-nfs"
5/5/2017 4:18:11 PMtime="2017-05-05T08:18:11Z" level=info msg=create.request name=1f888843-edd6-42a5-bbdb-d0a5e48a5874
5/5/2017 4:20:16 PMtime="2017-05-05T08:20:16Z" level=error msg=create.response error="Failed mount -o ,nfsvers=4 192.168.99.102:/ /tmp/zc9ty: mount.nfs: Connection timed out"
… and storage is inactive
@arjuneyy Hi i have the exact same error. did you manage to get any progress with it?
Unfortunately still no progress, it’s been a week already since I started working with this
Di you try logging into the Rancher node and make sure you can actually ping 192.168.99.102? From the look of it the rancher node is not getting a reply from your NFS server.
You should also be able to open a shell into one of your nfs-driver containers and issue a showmount -e 192.168.99.102 and see the list of exports, and confirm connectivity using ping
Hope this helps
-Barry Flanagan
1 Like
I was able to attach the volume in rancher.
Result:
- On the host acting as the server, install nfs-kernel-server.
- Create directories:
/exports/exports
/mnt/exports
/mnt/exports/home
- Perform “chmod 777” on /exports.
- Edit /etc/exports:
/mnt/exports 192.168.99.0/24(rw,sync,fsid=0,no_subtree_check)
/mnt/exports/home 192.168.99.0/24(rw,sync,nohide,insecure,fsid=0,no_subtree_check)
- Mount the volumes.
mount --bind /mnt/exports /exports/exports
- Start rpcbind service and nfs-kernel-server service.
NOTE: Every time I start the rpcbind service, I keep encountering an error. So to avoid this error create a specific directory needed to start the service.
mkdir -p /run/sendsigs.omit.d
service rpcbind start
service nfs-kernel-server start
My Rancher NFS Configuration:
image: rancher/storage-nfs:v0.6.0
environment:
MOUNT_DIR: /
MOUNT_OPTS: nfsvers=4
NFS_SERVER: 192.168.99.102 //(hostsip address)
For services:
version: '2'
volumes:
volume99:
external: true
driver: rancher-nfs
services:
efsadmin:
image: ubuntu:14.04.3
stdin_open: true
volumes:
- volume99:/exports
tty: true
labels:
io.rancher.container.pull_image: always
io.rancher.scheduler.global: 'true'
Hope this helps.
hello there everyone. i am having the exact same problem and been wondering if someone mananged to find an answer? i’m currently sitting home doing nothing but searching for pharmacyreviews.md because of my recent health issues and no money. but in the meantime i do nothing i wanted to learn and so i’m now here. please update! thanks for everything