Rsyncd with qrexec not working in 4.2 anymore (permission denied)

I’m following this guide: Guide: Rsync from multiple qubes to one over qrexec

It worked flawlessly in QubesOS 4.1 but for some strange reason not anymore with 4.2 (with the fedora-38-xfce template).

When I execute the rsync command in the VM to which I want to sync, I’m getting this error:

$ rsync -a --delete --stats --port=1873 localhost::syncdata /home/user/backup/qubes/backuptest
@ERROR: chroot failed
rsync error: error starting client-server protocol (code 5) at main.c(1859) [Receiver=3.2.7]

On the source VM, where rsyncd is running, I’m seeing this error:

Feb 04 20:36:22 backuptest rsyncd[1413]: rsync allowed access on module syncdata from localhost (
Feb 04 20:36:22 backuptest rsyncd[1413]: rsync: [Receiver] chroot("/home/user") failed: Permission denied (13)

I’ve started rsyncd as root but it didn’t make a difference.

It seem that the qrexec mechanism itself is working correctly and the sync request reaches across to the source VM but somehow over there in that VM, rsyncd thinks it doesn’t have enough permissions.

I’m getting the impression that something was changed in the new templates of 4.2 which might have broken this mechanism.

Any suggestions/ideas on how to troubleshoot or even fix this are highly appreciated! Thanks!

Since you are using the fedora template, this may be a selinux issue.
Can you run the following command and test again?

sudo setenforce 0
1 Like

Possibly related: qvm-copy now chokes if you copy symbolic links over to the other VM, even if you’re copying a whole folder and the link is a relative path to a target in that folder. It didn’t used to do that in 4.1.

1 Like

You’re my hero! That was indeed the issue and with this command it works now. Thanks very much!

I’ll now try to figure out whether I can change the policies just for rsync instead of setting everything to permissive mode.

Turns out that this simple command works for my use case:

sudo setsebool -P rsync_export_all_ro 1

It seems to allow read-only access to files/directory, which is what I need rsync to do in this case. See documentation here.

Based on this discussion there seem to be some edge cases, where this wouldn’t work but I didn’t come across them yet for my backup use case.

1 Like