#1147156 rsync 3.5.0 causes Incus VM startup failure under AppArmor

Package:
rsync
Source:
rsync
Description:
fast, versatile, remote (and local) file-copying tool
Submitter:
Zhéxué Matthias Krawutschke
Date:
2026-09-08 12:51:02 UTC
Severity:
normal
#1147156#5
Date:
2026-09-08 11:55:04 UTC
From:
To:
Dear Maintainer,

after upgrading a Debian Forky Incus host to the currently available packages, existing Incus virtual machines fail to start during setup of the VM agent device.

The affected package combination is:

rsync       3.5.0+ds1-2
incus       7.0.1-3
incus-agent 7.0.1-3
incus-base  7.0.1-3
apparmor    4.1.8-2

When starting an existing Incus virtual machine, Incus fails while copying the VM agent configuration:

Error: Failed to start device “agent”: Failed to run:
rsync -a -HA –sparse –devices –delete –numeric-ids –modify-window=-1 -q
/var/lib/incus/virtual-machines//config/
/var/lib/incus/devices//agent:

exit status 3

rsync: [Receiver] change_dir#1 “/var/lib/incus/devices//agent” failed:
Permission denied (13)

rsync error: errors selecting input/output files, dirs (code 3)
[Receiver=3.5.0]

The corresponding AppArmor audit event is:

apparmor=“DENIED”
operation=“open”
class=“file”
profile=“incus_rsync-”
name=”/”
comm=“rsync”
requested_mask=“r”
denied_mask=“r”
fsuid=0
ouid=0

The problem is reproducible with multiple existing Incus virtual machines.

As an A/B diagnostic test, disabling Incus’ AppArmor integration with:

INCUS_SECURITY_APPARMOR=false

allows the same virtual machines to start successfully after restarting the Incus daemon.

This strongly suggests an interaction between rsync 3.5.0 path handling and the dynamically generated Incus incus_rsync-* AppArmor profile.

The issue has already been reported to Incus upstream:

https://github.com/lxc/incus/issues/3968

There also appears to be a potentially related upstream rsync issue:

https://github.com/RsyncProject/rsync/issues/1064

That report describes rsync 3.5.0 requiring read permission for search-only directories due to directory descriptors being opened with read access. This appears potentially consistent with the AppArmor request observed here:

name=”/”
requested_mask=“r”

I cannot determine whether the appropriate fix belongs in rsync, Incus’ generated AppArmor profile, or both.

I am reporting this to Debian because the currently shipped Forky package combination can result in existing Incus virtual machines becoming unable to start after a routine package upgrade.

Downgrading rsync to an older release does not appear to be an appropriate general workaround because rsync 3.5.0 contains important security fixes.

Expected behaviour:
Existing Incus virtual machines should continue to start normally after the rsync 3.5.0 upgrade while Incus AppArmor confinement remains enabled.

Actual behaviour:
VM startup fails during the Incus agent-device rsync step because the generated incus_rsync-* AppArmor profile denies rsync read access to /.

Kind regards,
Zhéxué Matthias Krawutschke