NFS and VM Permissions

[chbelle]

Cockpit version: 224.2.
OS: Cent0S 8
Page: Virtual Machines, VM, Add Disk

This maybe an issue to do with NFS. When I create a new disk on block-based storage the file permissions are correctly set - and the VM starts-up.

When I create a disk on NFS mount the permission doesn't allow the VM to start.

The error in cockpit reads:

internal error: process exited while connecting to monitor: 2021-03-27T07:18:00.959587Z qemu-kvm: -blockdev {"driver":"file","filename":"/containers/test.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}: Could not open '/nfsexport/test.qcow2': Permission denied

The output of the ls command reads as:

-rw-------. 1 1024 users 193K Mar 27 2021 test.qcow2
-rwxrwxrwx. 1 1024 users 3.5G Mar 27 2021 os.qcow2

The odd thing when I do this on a block based storage - the permission on the test.qcow2 disk is also -rw....

[KKoukiou]

@chbelle this can possibly be a SELinux issue. Related docs here: https://libvirt.org/drvqemu.html#securityselinux
Short story, you need to enable the virt_use_nfs selinux boolean. To do so permanently:

setsebool -P virt_use_nfs=on

Please let me know if this worked for you.

[chbelle]

Katerina,

Thanks for your help and assistance :-)

Sadly, the setsebool didn't work for me. The interesting thing is even if I log in to cockpit as 'root' permissions problem appears. However, when I create the QCOW2 file at CLI the problem doesn't occur.

disk1 was created by cockpit UI and disk2 is created as root at the CLI

-rw-------. 1 1024 users 193K Mar 29 09:46 disk1.qcow2
-rwxrwxrwx. 1 1024 users 193K Mar 29 2021 disk2.qcow2

That was on the same NFS volume - and I used root in cockpit and root at the CLI.

If I use chmod at the command-line and manually change the permissions with:

chmod o+rwx disk1.qcow2

The error goes away and the VM starts without an error...

I think you are on the right lines though - this does seem NFS specific - because when I use cockpit using block storage, I don't have this issue adding the additional disk.

So I'm bit confused about what's happening...

best wishes
michelle

[KKoukiou]

Does the directory where the VMs images are located at has the execution privilege? sudo chmod +x /path/to/your/nfs/mountpoint

[chbelle]

and ls -lh on / shows the permissions as so:

drwxrwxrwx. 4 root root 4.0K Mar 29 2021 nfsexport

I did try the chmod +x but it came back that changing permissions of 'nfsexport': Operation not permitted

[KKoukiou]

@chbelle the VM you 're configuring is a session or system connection VM? From the image permissions I can assume session.
If it's session, the permission -rw-------. 1 youruser youruser should be enough, not need to open permissions more.

Qemu requires execution permission along the image file's path, and of course rw for the image itself. So you need to make sure that youruser is part of the necesary groups, that is libvirt.

[chbelle]

Hi there. It should be "system" connection - that's how the VM was created initially. I did my user account into libvirt (it wasn't a member) but sadly that didn't help...

Given this a problem on NFS storage but not on block storage - could it be something about NFS?

[KKoukiou]

Hey @chbelle, indeed, it's seems an NFS specific issue and very specific to your system. I just tried to reproduce locally, and I can actually run Vms with disks on NFS as expected. I have some more questions to be able to help you debugging, but at this point I will convert this issue to a discussion since it's specific to your system, and I will gladly follow there.

So how do you run the VM?

• Can you send me a screenshot of the create VM dialog options before you close it? I am interested on how you actually choose the destination storage of your disk. Is your default pool your NFS mountpoint?
• How do you export the directory on the server? cat /etc/exports

Sorry for the late reply.

[aaronprisk]

Sorry to re-open this discussion, but I'm seeing the same issue on my RHEL 8 setup. It seems to be an issue with NFS and root squashing.

If I manually create a VM volume or convert a VM using qemu-img from the terminal, the correct permissions are applied. If I use the Create Volume function in Cockpit, it creates the volume with nobody (nfs4) or 4294967294 (nfs3) as the owner.

I attached a screenshot showing the behavior:

[aaronprisk]

I created a fresh NFS share on a TrueNAS server this time and was able to correct the behavior by passing -maproot=MYUSER in the export listing.

I'm assuming the create volume function on Cockpit runs as root and therefore if the NFS server has squashroot enabled, it will create the volume with nobody or 4294967294 as the owner.

[KKoukiou]

Thanks for the hint, that's probable. I will take a look today.