NFS-Permissions when mounting shares

[s1lvester]

Hi all, I'm actually not sure if this is docker-volume-netshare's Problem or if it's just nfs but heres my issue:

1. NFS mounting works just fine. I'm able to mount, read write shares inside containers IF I choose a new mountpoint inside the container (-v /path/to/nfs:/new/path/inside/container)
2. When mounting an existing directory inside the container (f.i. to make the configs stateful) i'm getting strange permission errors from with chown or mount (-v /path/to/nfs:/path/to/exsisting/config/directory)

I think the container processes (db, webserver, etc.) are trying to chown their files or the whole directory - which of course fails because nfs doesn't let them since their UIDs are not known on the nfs-host.

Any Ideas on how to resolve this? I tried to mapall users but that didn't help either...

# /etc/exports
/path/to/share -alldirs -mapall=myuser:mygroup
/path/to/share2 -alldirs # doesn't work either

# bash
sudo docker-volume-netshare --verbose --version=4 --options="defaults,rw,hard,nolock" nfs

# Error Message:
Error response from daemon: chown /var/lib/docker-volumes/netshare/nfs/<IP>/<share>: invalid argument

docker v 1.12.1 os: rancher os v0.7.0

[shawly]

I'm having the same problem, with rancher-nfs, have you ever found the solution to this issue? I'm also using FreeBSD's NFS server, to be more specific, I'm using FreeNAS.

[s1lvester]

Im sorry to say, that I never found a solution. Instead I mounted freenas Samba shares locally on the docker-host and used regular volumes.

On 28. Jun 2017, at 11:06, shawly notifications@github.com wrote:

I'm having the same problem, with rancher-nfs, have you ever found the solution to this issue? I'm also using FreeBSD's NFS server, to be more specific, I'm using FreeNAS.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[shawly]

That's a bummer, but thanks for the reply!

[jonaskello]

I'm also using FreeNAS and have this exact same issue.

I read this which was helpful in understanding how NFSv4 does user mapping.

NFSv4 handles user identities differently than NFSv3. In v3, an nfs client would simply pass a UID number in chown (and other requests) and the nfs server would accept that (even if the nfs server did not know of an account with that UID number). However, v4 was designed to pass identities in the form of <username>@<id-map-domainname>. To function correctly, that normally requires idmapd (id mapping daemon) to be active at client and server, and for each to consider themselves part of the same id mapping domain.

This behaviour can be disabled by setting the following parameter for the kernel nfs module:

nfs.nfs4_disable_idmapping=1

I'm running Ubuntu 16.04 and were able to check this parameter with this command:

$ systool -vm nfs
...
nfs4_disable_idmapping= "Y"
...

Seems like this is disabled by default in newer kernels, as mentioned in the link above:

The NFS community has recognized that this idmapd feature of NFSv4 is often more troublesome that it is worth, so there are steps and modifications coming into effect to allow the NFSv3 behavior to work even under NFSv4. In mainstream Linux, the default behavior changes in kernel 3.3, i.e. to already have nfs4_disable_idmapping set to 1.

However, it also seems both sides must have this set:

Some NFSv4 servers may not be prepared to accept this behavior, either. Both sides need to understand this change.

So my guess now is that FreeNAS does not have this disabled for NFSv4.

[jonaskello]

I found a solution that works for me with FreeNAS 11.0 and Ubuntu 16.04.

The key is that the NFS4 server and NFS4 client must either both have user mapping enabled, or both have it disabled. Ubuntu has it disabled as default. The solution for me was to also disable it in FreeNAS. To do that in the FreeNAS UI you you enable this option: Services > Control Services > NFS (click the wrench) > NFSv3 ownership model for NFSv4.

Some additional information is available here.

[shawly]

@jonaskello Damn dude, this looks like it could work, I'll try it this weekend, thank you!

I want to add that Rancher-NFS now supports NFSv3, so Rancher OS should now also work with FreeNAS, (even though I haven't tried since Rancher had some heavy issues in a virtual machine for me so I had to reinstall it multiple times because I found no way to troubleshoot these issues..)