Incus file pull/push Strange Slowness

m1g0r3ng · May 3, 2026, 3:28am

Hi!

My goal is to transfer a file from instance c1 to instance c2 within Incus. I’m trying the file pull from c1 then push to c2 method.

I’m running incus latest stable and on a local network, I’ve set the instance c1 and c2 to direct attach to the network. The client is on the same network but on the WiFi.

If I run incus file pull c1/bigfile . the speeds I get are around 5 MB/s.

Using croc I get around 80 MB/s, closer to what I’d expect.

Out of curiosity, I added c2 as a trusted incus client to test a file pulling from c1 and the speeds were around 260 MB/s.

Is there a way to speed up this transfer or would it be a misconfiguration on my end?
Is there a better or best-practice way to transfer a file from one incus instance to the other directly?

Thank you for all your work

candlerb · May 6, 2026, 10:47am

It shouldn’t make any difference how the containers “attach to the network”: you’re talking to the incus daemon running on the physical host, not to the containers. Indeed, these pull/push operations should work even if the containers are stopped.

I have not come across “croc” before. Do you mean this? If you’re using it to transfer directly from c1 to c2 (both wired), then this is not a fair comparison to transfer from c1 to client device (wireless). Or are you running croc inside c1 and also on the wireless client?

To debug further, I suggest installing iperf3 on both the server host and the client. Run “iperf3 -s” on the server, and then “iperf3 -c x.x.x.x -R” on the client, to test the potential throughput available over wireless.

Also: you should specify the version of incus you’re running, and the underlying operating system.

m1g0r3ng · May 7, 2026, 2:28am

Hi @candlerb! Thank you for enlightening me on how this works and for the pointers. You’re right I should’ve put more information before posting^^ I will gather my findings below:

Server IP: 192.168.0.10
Server OS: Debian 13 Stable
Incus Client version: 7.0.0 — (bin.macos.incus.aarch64)
Incus Server incus version: 7.0.0 — (zabbly incus repo)
Incus Storage driver: dir on ext4 (default admin init)

Here are iperf3 results from client:

% iperf3 -c 192.168.0.10 -R
Connecting to host 192.168.0.10, port 5201
Reverse mode, remote host 192.168.0.10 is sending
[  5] local 192.168.0.55 port 49224 connected to 192.168.0.10 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  78.2 MBytes   653 Mbits/sec                  
[  5]   1.01-2.00   sec  84.1 MBytes   707 Mbits/sec                  
[  5]   2.00-3.00   sec  73.2 MBytes   615 Mbits/sec                  
[  5]   3.00-4.00   sec  71.2 MBytes   597 Mbits/sec                  
[  5]   4.00-5.00   sec  76.1 MBytes   639 Mbits/sec                  
[  5]   5.00-6.00   sec  78.0 MBytes   655 Mbits/sec                  
[  5]   6.00-7.00   sec  79.1 MBytes   664 Mbits/sec                  
[  5]   7.00-8.00   sec  76.8 MBytes   643 Mbits/sec                  
[  5]   8.00-9.00   sec  79.0 MBytes   662 Mbits/sec                  
[  5]   9.00-10.00  sec  81.0 MBytes   681 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   780 MBytes   654 Mbits/sec    0            sender
[  5]   0.00-10.00  sec   777 MBytes   652 Mbits/sec                  receiver

Then I run the following from client:

% incus stop c1

% incus file pull c1/root/bigfile .
Pulling bigfile from /root/bigfile: 59.54MB (5.40MB/s)^C

% sftp root@192.168.0.10:/var/lib/incus/containers/c1/rootfs/root/bigfile .
Fetching /var/lib/incus/containers/c1/rootfs/root/bigfile to ./bigfile
/var/lib/incus/containers/c1/r...  23%  956MB  78.0MB/s   00:40 ETA^C

I’ve seen similar results on other clients on WiFi, I don’t have an ethernet cable to test with me right now but I’ll update if I do test and get different results with that. Thank you again!

candlerb · May 7, 2026, 10:16am

I don’t know what the problem is then, but if you can reproduce it over a cabled connection then it’s worth raising an issue for.

FWIW, I do see about the same as you over wireless (802.11ac = wifi 5, Macbook Pro M3 as the client, incus 6.23 on server):

% incus file pull kit:cndo/var/lib/GNS3/images/QEMU/ubuntu-22.04-server-cloudimg-amd64-20221214.img .
Pulling ubuntu-22.04-server-cloudimg-amd64-20221214.img from /var/lib/GNS3/images/QEMU/ubuntu-22.04-server-cloudimg-amd64-20221214.img: 218.92MB (5.45MB/s)^C

It’s 5 times faster on wired:

% incus file pull kit:cndo/var/lib/GNS3/images/QEMU/ubuntu-22.04-server-cloudimg-amd64-20221214.img .
Pulling ubuntu-22.04-server-cloudimg-amd64-20221214.img from /var/lib/GNS3/images/QEMU/ubuntu-22.04-server-cloudimg-amd64-20221214.img: 446.30MB (24.77MB/s)

but still not what gigabit can achieve, which is 4 times faster again:

% scp s1e:/var/lib/GNS3/images/QEMU/ubuntu-22.04-server-cloudimg-amd64-20221214.img .
ubuntu-22.04-server-cloudimg-amd64-20221214.img                                                                                    69%  445MB 110.2MB/s   00:01 ETA^C

Taking the middle case (incus pull, wired ethernet): running “top” on both client and server shows “kernel_task” at around 110% of a CPU on the client side. I wonder if too small a buffer is being used for I/O?