Hide Forgot
Description of problem: The files contained in the subdirectories of /var/lib/cinder/mnt/*/* have 666 rights set. We expects 660 rights of 600. Where are you experiencing the behavior? What environment? Production. We use the driver Netapp Ontapp NFS Version-Release number of selected component (if applicable): [root@vel1-nfv01-cont0108 ~]# rpm -qa | grep cinder python-cinder-2014.2.3-3.1.el7ost.noarch python-cinderclient-1.1.1-1.el7ost.noarch openstack-cinder-2014.2.3-3.1.el7ost.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
NFS security enhancements were introduced in Kilo (RHEL OSP7) [1]. We'll check if they are backportable to RHEL OSP6. [1] https://review.openstack.org/#/c/107693
Any chance the customer will set 'debug=True' in cinder.conf and restart cinder services? I suspect we're not seeing the whole story in the scheduler log in the sos report as to why the scheduler doesn't start up right in their environment.
In the current log we see not only failure to 'chmod 660' the backing files for cinder volumes but also failure to remove such files ===================================================== 2016-03-23 09:58:26.089 8663 TRACE oslo.messaging.rpc.dispatcher Stderr: 'rm: cannot remove \xe2\x80\x98/var/lib/cinder/mnt/942b880ce09810131260eb1c5bc1b714/volume-ee41c0c5-cb9b-44d5-b3bd-289f347b075b\xe2\x80\x99: Permission denied\n' ====================================================== Because 'nas_secure_file_operations=True' is set, these 'chmod' and 'rm' operations are being run as the 'cinder' user without elevating privileges to root. The operations are failing because the share being exported from the NetApp filer doesn't have ownership and permissions set up to grant those permissions to the cinder user. There are two ways forward. It is pretty reasonable to set 'nas_secure_file_operations=False' and 'nas_secure_file_permissions=True'. That way the controller/storage node is still allowed to elevate permissions when performing these operations but permissions on the backing files for the volumes are still set to 660 rather than being 666. That was I think the motivation for asking for this backport. Alternatively, if you want to run all operations on the backing files for cinder volumes without any elevation of privilege then you have to modify ownership, permissions, and potentially export options _on the NetApp filer_ so that the share is exported with permissions that allow the cinder operation to create, chmod, and rm anything in the exported share. If you go this way, be sure to test outside of OpenStack that you can 'sudo cinder chmod 660 <file>', 'sudo rm <file>', etc. files in the exported share. Note that you likely have pre-existing volumes owned by root whose ownership would need to be changed on the exported share before OpenStack will be able to operate on them.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions