Run this command in destination qube and try one more time:
sudo setenforce 0
One step closer! After running this command, I am not getting “permission denied” error when trying to copy from source to destination qube. I can see the progess of copying and right before the end this error is displayed:
qfile-agent: Fatal error: File copy: "Operation not permitted; Last file: test.txt" (error type: Operation not permitted)
But the file is actually copied and seems to be fine. The error is also displayed when copying with the GUI. The same happens if I configure it back to the original permissions (NFS target using user with id 1001 while qubes are using user with id 1000 - but I guess all access is mapped to that 1001 user).
When I wrote my instructions, I was going from memory, and my memory is faulty. I was thinking more in the mode of creating a mount point than creating a soft link.
For a mount point, of course, you want an empty directory there, to serve as your mount point. But with a soft link there cannot be a prexisting file with that name. And that’s exactly the opposite of what I told people to do.
What’s there now is shorter, but should work. (I usually do the “general” case where I simply softlink to QubesIncoming and sort things out after the copy, by the way. The general case is now gone from the description, but that’s fine.)
I guess my sys-usb suggestion was unsuitable and got completely deleted.
I think the “operation not permitted” might be because qvm-copy is trying to chown after copying the file, which might not be allowed on the NFS destination. Is there anything I can do to change that behavior?
Would setenforce 0 in /rw/config/rc.local be an acceptable solution or is it worth to incorporate into SELinux and to try to create a matching policy?
@SteveC I split the thread, so please update the top post and the corresponding entry in the Quick QoL thread once you’ve settled on one or more methods that work for everyone. The Quick QoL should be the bare minimum that just works, so caveats, considerations, discussions, etc. should go in the top post here.
Also, your sys-usb suggestion is still alive and kicking after I condensed it, and your original post is also preserved in its full glory:
Your suggestions are among the most popular (and controversial) in the thread, so keep at it!
I actually don’t seem to understand the way permissions are handled.
When configuring the NFS share on the server with mapall user and mapall group to user and setting the permissions on the server to user/group=full access I am able to mount the share from qubes and access everything. Except the qvm-copy throws an operation not permitted error after copying because it probably tries to chown as root.
When configuring the NFS share on the server with maproot user and maproot group to user I am not able to access the mounted share in qubes anymore. But if I try to access it with sudo cd QubesIncoming I am actually able to access it. So in that case it seems to be only accessible by the root user.
I have no idea how to configure it on the server side so that all access is mapped to user nevermind if this is a qubes-user or a qubes-root access.
I’ve been having a similar issue since upgrading to 4.2–Whenever I mount an external drive, I have to also chown user /mnt/mountPoint in order to write (and sometimes to read too),
There are other bugs with qvm-copy and qvm-move (like inconsistent and fatal mishandling of some non-unicode characters in filenames) that have popped up too.
I give up. I spent so many hours now on trying to get that working but it won’t work. I am not able to copy from qube A to qube B which contains a nfs share mounted. Copying to qube B and then copying into the nfs share works without problems but the simplification to directly copy to the nfs share will not work for me. Sad bud true
Edit: I finally tweaked the NFS share to allow user and root access at the same time. In a terminal in qube B I am able to cd into the share and to create files and I am also able to sudo chown a file. But still when copying from qube A to qube B, the file is actually copied and then an operation not permitted error is thrown
What if you do it from dom0 (not super practical though)
This does actually copy a file without giving an error, but the file is empty. qvm-run NAME_OF_SOURCE_QUBE "cat /home/user/Downloads/test.txt"
does not show anything but does not throw an error either.
That does actually work without problems, the file is directly copied from qube A to nfs share in qube B without any error.
Because sudo chown in qube B now (with changed NFS share configuration) does work my assumption that qvm-copy performs chown at the end is probably wrong. I don’t know what qvm-copy tries to do after the copying is finished and therefore I don’t know what actually causes the operation not permitted.
Here is the exact error message again, maybe you can see any other important information in it. qfile-agent: Fatal error: File copy: "Operation not permitted; Last file: test.txt" (error type: Operation not permitted)
I now moved the mount point from /mnt/remote to /home/user/remote but the error still occurs.
It’s your NFS share that is misconfigured, it works for me.
Are you using NFSv3 oder NFSv4 (as I do)?
Do you also have to disable SELinux in the remote qube?
And just to make sure: You are copying from a different qube A to qube B which links the folder of the incoming qube directly to the mounted NFS share?
I now created two more qubes running debian for testing, but the same error occurs.
Are you sure you are using NFSv4, I thought mount -t nfs4 would be required for that?
I added to rc.local
mkdir /home/remote
mount -t nfs4 -o proto=tcp,port=2049 NFS-PATH /home/remote
So I might try NFSv3 for testing, but this is actually not really an option because other systems are mounting different shares on that server with NFSv4.
Yes. I didn’t realize you had moved it under “input devices.” Thanks!
What you have there looks good actually. Very minimalist with little explanation, but now I see that this is what we’re after here. The general option (where the mounted offline storage ends up with a top level directory /[ORIGIN_QUBE]) is the easiest and that’s what’s described. There are of course a zillion variations on this! (Including the one where you link to ~QubesIncoming/[ORIGIN_QUBE]). We can rely on users to figure that out once we give them the initial idea.
For instance I’m going to have to download the 4.2 ISO at some point, and I’m going to have to get creative about how to accommodate that file. Mounting offline storage (in this particular case it will be a thumb drive) to ~/Downloads will do it, I think. And really that’s just the same tip, reworked slightly.
Yeah, well, the controversy is my fault; my original steps were defective. I hope there’s no more damage from that going forward.
I don’t see how there’s actual damage, but as long as the top post here and the Quick QoL entry are both updated with tested instructions, everything should be fine.
