Hi list,

We’ve got a curious issue here. We’re trying to configure Cinder for use with NetApp NFS. The NetApp has been configured to disallow superuser access and cinder has been set up with nas_secure_file_operations set to true.

While operations like creating volumes work, attaching a volume to an instance fails with the following traceback:

Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py", line 4369, in _connection_create conn_info = self.driver.initialize_connection(volume, connector) File "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/nfs.py", line 134, in initialize_connection volume['name']) File "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/nfs.py", line 543, in _qemu_img_info run_as_root=True) File "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/remotefs.py", line 765, in _qemu_img_info_base run_as_root=run_as_root) File "/usr/lib/python2.7/dist-packages/cinder/image/image_utils.py", line 111, in qemu_img_info prlimit=QEMU_IMG_LIMITS) File "/usr/lib/python2.7/dist-packages/cinder/utils.py", line 126, in execute return processutils.execute(*cmd, **kwargs) File "/usr/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 425, in execute cmd=sanitized_cmd) ProcessExecutionError: Unexpected error while running command. Command: /usr/bin/python -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C qemu-img info --force-share /var/lib/cinder/mnt/1be0f17801f5c315c80d99a59518e26e/volume- ae4bba9b-2ab3-4234-8f86-352f1a20e086 Exit code: 1 Stdout: u'' Stderr: u"qemu-img: Could not open '/var/lib/cinder/mnt/ 1be0f17801f5c315c80d99a59518e26e/volume-ae4bba9b-2ab3-4234-8f86-352f1a20e086': Could not open '/var/lib/cinder/mnt/1be0f17801f5c315c80d99a59518e26e/volume- ae4bba9b-2ab3-4234-8f86-352f1a20e086': Permission denied\n"

It seems as if cinder executes qemu-img as root. This is confirmed by looking at the code [3]. Looking at the superclass [4], we see that the superclass would’ve decided based on the setting of nas_secure_file_operations if [3] would not pass execute_as_root as True.

To us, it makes no sense whatsoever. While [1] mentions something about incorrect permissions on volumes, it does not seem to consider the case of running with NFS Security enabled at all.

However, it also seems as if this change went through completely uncontested. Hence, we assume that we are in the wrong here and wanted to ask on the mailing list instead of filing a bug.

Does anyone have insight on what we’re doing wrong / missing here?

kind regards, Jonas

[1]: https://review.opendev.org/#/c/461134/ [2]: https://github.com/openstack/cinder/commit/dbc9c7ca [3]: https://github.com/openstack/cinder/blob/stable/queens/cinder/volume/ drivers/nfs.py#L537-L543 [4]: https://github.com/openstack/cinder/blob/stable/queens/cinder/volume/ drivers/remotefs.py#L753-L761 [5]: https://github.com/openstack/cinder/blob/stable/queens/cinder/volume/ drivers/nfs.py#L431-L432