Comment 1 for bug 1598111

The problem is posix file ownership problem:

root@node-30:/var/lib/cinder/mnt# mount | grep nfs
172.21.22.252:/vol/vol1 on /var/lib/cinder/mnt/bfe0522da8ec08bea42affcc3f7831bf type nfs (rw,vers=4,addr=172.21.22.252,clientaddr=172.21.43.4)

root@node-30:/var/lib/cinder/mnt# ll
total 16
drwxr-xr-x 3 cinder cinder 4096 Jun 20 17:56 ./
drwxr-xr-x 4 cinder cinder 4096 Jun 20 17:56 ../
drwxrwxr-x 59 nobody 4294967294 8192 Jul 5 20:43 bfe0522da8ec08bea42affcc3f7831bf/

I guess earlier, cinder was running as root, so permissions on the mounted NFS share didn't matter.
Now that cinder runs as user "cinder", creation of files on an NFS share with ownership user "nobody"
and group "$maxint32" doesn't work when the mount point has permissions 0775, as user "cinder" is part of "other" and thus not permitted to write (create a file).

We have no older working installations and can only guess that in earlier versions (FUEL 6.1, Juno) cinder was running as root... thus the weird permissions on the NFS share didn't matter.

So - unclear what the proper fix is. Beating the NetApp share into "fitting" permissions for the share prolly isn't a sensible path. A better way would be for the cinder node to mount the NFS share with NFS mount options forcing the NFS share's permissions to be UID=cinder (and prolly GID=cinder as well). This way, it doesn't matter what the NFS filesystem's original ownership are, but locally on the cinder node all NFS share files/folders are "owned" by the local UNIX "cinder" user under which cinder as a service operates.

Best regards,
Daniel