rancher: Not able to start services with stack scoped volumes in rancher-nfs

Rancher Versions: Build from master

Environment - cattle with rancher-nfs - rancher/storage-nfs:v0.6.0 Create a stack using the following yml:

version: '2'
services:
  nginx3:
    image: nginx
    volumes:
    - foo3:/tmp

volumes:
  foo3:
    driver: rancher-nfs
    external: false

Sangeethas-MacBook-Pro:rancher-compose-v0.12.1 sangeethahariharan1$ ./rancher-compose -p new1 -f test1.yml up INFO[0000] Creating volume template foo3
INFO[0000] [0/1] [nginx3]: Creating
INFO[0000] Creating service nginx3
INFO[0000] [0/1] [nginx3]: Created
INFO[0000] Existing volume template found for foo3
INFO[0000] [0/1] [nginx3]: Starting
INFO[0005] [1/1] [nginx3]: Started
ERRO[0006] Failed to get logs for new1-nginx3-1: Failed to find action: logs

Stack scoped Volume gets created - new1_foo3_82c63 but it in “Dactched” state. Containers fail to start with the following exception: Activating (Expected state running but got error: Error response from daemon: chown /var/lib/rancher/volumes/rancher-nfs/new1_foo_3e06f: operation not permitted

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 20 (4 by maintainers)

Most upvoted comments

I was having the same issue while trying to use a rancher-nfs volume in a elasticsearch container. The problem was my nfs server permissions, I had to enable “no_root_squash” so the container could access as root. Otherwise it will try to use “nobody,nogroup”.

More info here:

no_root_squash: By default, NFS translates requests from a root user remotely into a non-privileged user on the server. This was intended as security feature to prevent a root account on the client from using the file system of the host as root. no_root_squash disables this behavior for certain shares.

So your exports should look like this: /nfs [ip](rw,sync,no_root_squash,no_subtree_check)

I haven’t been able to get around the problem. I’m using FreeNAS which is BSD based and they don’t have a no_root_squash. I’ve tried maproot as root and mapall as root, but both still run into the chown issue.

I believe setting up NFSv4 in an existing environment or without endless financial resources is impossible. Most people will end up disabling some core features with no_root_squash, which is, in my eyes, not a good solution. And it’s not possible in lots of environments (we’re using Solaris ZFS on a huge storage cluster - that thing is stable like a tank but - you guess - no option for no_root_squash).

I can’t believe how many hours I wasted to setting up NFSv4 in our company just because of rancher-nfs and long story short: it still isn’t working and messing with my permissions. The one and only generic solution to NFSv4 that I read over and over again is switching to NFSv3.

Tested with rancher/storage-nfs:v0.8.0 using rancher-server version - v1.6.0-rc1

Able to create volume and attach them to containers successfully when following setting are done for mount points on the nfs server:

/var/nfs *(rw,sync,no_subtree_check,no_root_squash)