If you need to move/copy a LARGE file from one qube to another, and you’re going to put that large file onto some sort of external storage at the destination, you might be concerned about the useless write to your SSD involved in copying to the destination’s QubesIncoming directory. Or the file might be too large to fit!
Simple solution: on the destination, replace QubesIncoming (or QubesIncoming/) with a soft link to someplace on your external storage. That way the qvm-copy (or qvm-move) goes directly to your external storage and you don’t have to worry about an extra write to an SSD, or the file being too big for the destination qube’s allocated space. (I played around with mounting ramdisks and the like,then realized this was much simpler and still works.)
This involves that the external storage is mounted in /mnt/external_storage/, and that ~/QubesIncoming directory will be deleted along with its content, so you should not keep anything in it.
Looking over this again and testing it I’ve fixed a little error in the “general implementation”, but I can’t get your “special” solution (with the VM folder already existing) to work unless using it the same way as the general implementation. On my system if I do ln -s /mnt/ QubesIncoming/vmname (with a pre-existing folder vmname) it will create the symlink inside that folder and so this solution won’t work. I can only get it to work by creating the symlink instead of the folder.
Also I’ve found that on Fedora-based VMs there are permissions problems; on Debian-based VMs it seems to work fine, at least the general solution does. I don’t have more time to test this, but that’s what I’ve found. In any case, the general solution seems to work well enough, at least on Debian.
It’s a reply to SteveC’s post; the forum for some reason often does not show that posts are replies…possible forum bug @deeplow (noticed this many times now).
@solene’s code is erroneous IMO because the final forward slash in the second line shouldn’t be there, as we’re removing those directories and then placing a symlink instead
@SteveC’s second (special) method where a particular qube destination folder is linked doesn’t work for me at all unless I use it the same way I use the first (general) method, so that part of the guide it seems needs to be removed or tested. I also noticed that even the general method doesn’t work if the target qube is based on fedora-38-xfce, because qvm-copy will throw a permission error; on debian-12-xfce it works.
you need to ensure user user can write on the mounted drive
my code removes ~/QubesIncoming completely, so I don’t create a target symlink per origin qube
lrwxrwxrwx. 1 user user 21 5 janv. 09:48 QubesIncoming -> /mnt/external_storage
If you want a per qube link, ln -s /mnt/storage/QubeName ~/QubesIncoming/ will work as it will create QubeName within ~/QubesIncoming/ that will go in /mnt/storage/QubeName
Anybody know what I am doing wrong? I guess there should be no permission trouble if “user” is able to copy data to the nfs targed directly in the destination qube, shouldn’t it?
The user user should be allowed to write on the device. On the NFS target, you may need to chown the shared directory to the same uid as in the qube (default is 1000) (this can be found using id). By doing so, the user ID of the NFS server directory will be the same as the local system.
Hmm. But in the destination qube, where I mounted the NFS target I am able to copy and modify data in the target, so I guess the qube user (id 1000) is mapped to a corresponding user with permissions (actually id 1001 in the destination).
I now created a user with id 1000 in the destination (belonging to group 1000), added permissions to that user (and group) on the destination, adjusted the NFS share to map all access to user/group 1000.
I am then able to copy/modify when working directly in the destination qube.ls -l even shows that new files are belonging to user/group user. But again, when trying to copy from a different source qube to the destination qube the same “permission denied” error is shown.
Source/destination qubes are both using fedora-38-xfce.
I’ve also encountered this when the destination qube was using fedora-38-xfce…with debian-12 based destination qube it worked. SEL does sound like a possibility here.
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!
