Hi, I've been using pasta as a network driver for rootless docker and I've been running into a couple of issues for a while now. I hope this is where I can find some help troubleshooting. The issue is that when I use pasta as the network driver as opposed to slirp4netns, I'm unable to access the internet through rootless docker or use ping (or traceroute) through its containers. So if I run "docker pull <image-name>" I get a timeout error:
Using default tag: latest Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 10.0.2.3:53: read udp 169.254.2.1:58905 ->10.0.2.3:53: i/o timeout
I'm running pasta version 0.0~git20250217.a1e48a0-1 on Ubuntu 24.04.2 LTS with docker v27.3.1 build ce12230. Please let me know what other details I could provide to troubleshoot this issue. Thanks and regards, Ayon Tarafdar
Hi, sorry it has been a while, I haven't been able to find the time to work
on this problem.
However, I think I've managed to narrow down what the problem is, so I'm
writing to you again!
I essentially ended up using a wrapper for pasta to try out a few different
arguments with it, even though I went down a different route. I used
"DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS" with `rootlesskit` to pass on a new
location to a script wrapping the pasta binary.
I passed on the explicit local network IP of the DNS server that runs on my
home network, and everything started working fine.
I'll explain: my server PC runs rootless containers – one of them runs a
DNS server. On that PC itself, I redirect local DNS queries to 127.0.0.1
(the first nameserver on /etc/resolv.conf). pasta picks up the first entry
on /etc/resolv.conf and forwards DNS queries to it. But it seems like it
cannot access localhost (probably by design?)
Once I add the local network IP (192.168.x.y) explicitly as the DNS server
to forward queries to, things work, but I find this inefficient as it feels
like queries shouldn't have to go through the local network for resolution,
since the DNS server runs on that very device.
Please advise me on what can be done about this and if I'm on the wrong
track.
Regards,
Ayon
On Tue, Jun 3, 2025 at 8:16 AM Stefano Brivio
On Fri, 23 May 2025 00:51:25 -0230 Ayon T
wrote: I know you have been asking me to run pasta with arguments with docker, but I'm not sure how to do this (pardon my inexperience). I use an override.conf file to set the default network and port driver of docker, and that's how I use pasta with docker. I have tried looking up how to do it in a different way that gives me more control over the arguments that go in, but I haven't been able to find it. Could you guide me regarding this or point me to a resource?
Apologies for the delay. It looks like you need to rebuild rootlesskit with any option you want to add, here:
https://github.com/rootless-containers/rootlesskit/blob/e83d7635183e1125798b...
because there's currently no convenient command-line mechanism like the one implemented by Podman, here:
https://github.com/containers/common/blob/5a4ca2d5d35571556f6e7d1d5f024c19dc...
I guess it would be nice to implement something similar, but I'm not really familiar with rootlesskit otherwise. An alternative could be to use a trivial wrapper at /usr/local/bin/pasta, a simple script doing:
-- #!/bin/sh
/usr/bin/pasta $@ --whatever-additional-option-here --
-- Stefano
On Mon, Nov 24, 2025 at 08:10:35PM -0330, Ayon T wrote:
Hi, sorry it has been a while, I haven't been able to find the time to work on this problem.
However, I think I've managed to narrow down what the problem is, so I'm writing to you again!
I essentially ended up using a wrapper for pasta to try out a few different arguments with it, even though I went down a different route. I used "DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS" with `rootlesskit` to pass on a new location to a script wrapping the pasta binary.
I passed on the explicit local network IP of the DNS server that runs on my home network, and everything started working fine.
I'll explain: my server PC runs rootless containers – one of them runs a DNS server. On that PC itself, I redirect local DNS queries to 127.0.0.1 (the first nameserver on /etc/resolv.conf). pasta picks up the first entry on /etc/resolv.conf and forwards DNS queries to it. But it seems like it cannot access localhost (probably by design?)
With its own default options, pasta will generally allow access from loopback, but docker may (by design) add parameters that override that behaviour. Using 'ps' (or your wrapper) to find out the exact arguments that docker is invoking pasta with would help.
Once I add the local network IP (192.168.x.y) explicitly as the DNS server to forward queries to, things work, but I find this inefficient as it feels like queries shouldn't have to go through the local network for resolution, since the DNS server runs on that very device.
So, yes, it arguably should be possible to access the server via 127.0.0.1. That said, I don't think there's any real inefficiency here: the kernel will already direct traffic to a public-but-local address over 'lo', so it won't actually hit the external network.
Please advise me on what can be done about this and if I'm on the wrong track.
Regards, Ayon
On Tue, Jun 3, 2025 at 8:16 AM Stefano Brivio
wrote: On Fri, 23 May 2025 00:51:25 -0230 Ayon T
wrote: I know you have been asking me to run pasta with arguments with docker, but I'm not sure how to do this (pardon my inexperience). I use an override.conf file to set the default network and port driver of docker, and that's how I use pasta with docker. I have tried looking up how to do it in a different way that gives me more control over the arguments that go in, but I haven't been able to find it. Could you guide me regarding this or point me to a resource?
Apologies for the delay. It looks like you need to rebuild rootlesskit with any option you want to add, here:
https://github.com/rootless-containers/rootlesskit/blob/e83d7635183e1125798b...
because there's currently no convenient command-line mechanism like the one implemented by Podman, here:
https://github.com/containers/common/blob/5a4ca2d5d35571556f6e7d1d5f024c19dc...
I guess it would be nice to implement something similar, but I'm not really familiar with rootlesskit otherwise. An alternative could be to use a trivial wrapper at /usr/local/bin/pasta, a simple script doing:
-- #!/bin/sh
/usr/bin/pasta $@ --whatever-additional-option-here --
-- Stefano
_______________________________________________ user mailing list -- passt-user@passt.top To unsubscribe send an email to passt-user-leave@passt.top
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
Hi,
Thanks for your insights! I've tried taking a look at the arguments with
which pasta is being invoked before. Right now, with my additional
dns-host argument,
this is what it looks like:
/usr/bin/pasta --dns-host=192.168.x.y --stderr --ns-ifname=tap0 --mtu=65520
--config-net --address=10.0.2.100 --netmask=24 --gateway=10.0.2.2
--dns-forward=10.0.2.3 --no-map-gw --ipv4-only --tcp-ports=auto
--udp-ports=auto 1722
and rootlesskit is invoked in the following way:
rootlesskit --state-dir=/run/user/1000/dockerd-rootless --net=pasta
--mtu=65520 --slirp4netns-sandbox=auto --slirp4netns-seccomp=auto
--disable-host-loopback --port-driver=implicit --copy-up=/etc
--copy-up=/run --propagation=rslave --pasta-binary /home/username/pst
/usr/bin/dockerd-rootless.sh
I've tried getting rid of the --disable-host-loopback option from
rootlesskit and the --no-map-gw option from pasta, but it hasn't helped.
On Wed, Nov 26, 2025 at 12:28 AM David Gibson
On Mon, Nov 24, 2025 at 08:10:35PM -0330, Ayon T wrote:
Hi, sorry it has been a while, I haven't been able to find the time to work on this problem.
However, I think I've managed to narrow down what the problem is, so I'm writing to you again!
I essentially ended up using a wrapper for pasta to try out a few different arguments with it, even though I went down a different route. I used "DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS" with `rootlesskit` to pass on a new location to a script wrapping the pasta binary.
I passed on the explicit local network IP of the DNS server that runs on my home network, and everything started working fine.
I'll explain: my server PC runs rootless containers – one of them runs a DNS server. On that PC itself, I redirect local DNS queries to 127.0.0.1 (the first nameserver on /etc/resolv.conf). pasta picks up the first entry on /etc/resolv.conf and forwards DNS queries to it. But it seems like it cannot access localhost (probably by design?)
With its own default options, pasta will generally allow access from loopback, but docker may (by design) add parameters that override that behaviour. Using 'ps' (or your wrapper) to find out the exact arguments that docker is invoking pasta with would help.
Once I add the local network IP (192.168.x.y) explicitly as the DNS server to forward queries to, things work, but I find this inefficient as it feels like queries shouldn't have to go through the local network for resolution, since the DNS server runs on that very device.
So, yes, it arguably should be possible to access the server via 127.0.0.1. That said, I don't think there's any real inefficiency here: the kernel will already direct traffic to a public-but-local address over 'lo', so it won't actually hit the external network.
Please advise me on what can be done about this and if I'm on the wrong track.
Regards, Ayon
On Tue, Jun 3, 2025 at 8:16 AM Stefano Brivio
wrote: On Fri, 23 May 2025 00:51:25 -0230 Ayon T
wrote: I know you have been asking me to run pasta with arguments with docker, but I'm not sure how to do this (pardon my inexperience). I use an override.conf file to set the default network and port driver of docker, and that's how I use pasta with docker. I have tried looking up how to do it in a different way that gives me more control over the arguments that go in, but I haven't been able to find it. Could you guide me regarding this or point me to a resource?
Apologies for the delay. It looks like you need to rebuild rootlesskit with any option you want to add, here:
https://github.com/rootless-containers/rootlesskit/blob/e83d7635183e1125798b...
because there's currently no convenient command-line mechanism like the one implemented by Podman, here:
https://github.com/containers/common/blob/5a4ca2d5d35571556f6e7d1d5f024c19dc...
I guess it would be nice to implement something similar, but I'm not really familiar with rootlesskit otherwise. An alternative could be to use a trivial wrapper at /usr/local/bin/pasta, a simple script doing:
-- #!/bin/sh
/usr/bin/pasta $@ --whatever-additional-option-here --
-- Stefano
_______________________________________________ user mailing list -- passt-user@passt.top To unsubscribe send an email to passt-user-leave@passt.top
-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
Hi Ayon,
On Sat, 10 May 2025 21:26:29 -0230
Ayon T
Hi,
I've been using pasta as a network driver for rootless docker and I've been running into a couple of issues for a while now. I hope this is where I can find some help troubleshooting.
The issue is that when I use pasta as the network driver as opposed to slirp4netns, I'm unable to access the internet through rootless docker or use ping (or traceroute) through its containers. So if I run "docker pull <image-name>" I get a timeout error:
Using default tag: latest Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 10.0.2.3:53: read udp 169.254.2.1:58905 ->10.0.2.3:53: i/o timeout
I'm running pasta version 0.0~git20250217.a1e48a0-1 on Ubuntu 24.04.2 LTS with docker v27.3.1 build ce12230.
I suspect you might be hitting this: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2077158 ...which is fixed on Ubuntu 24.10 and later versions. As a workaround, I guess you can create the AppArmor profile for pasta manually, from: https://passt.top/passt/tree/contrib/apparmor/usr.bin.pasta or set /proc/sys/kernel/unprivileged_userns_apparmor_policy to 0, see also: https://github.com/kubevirt/kubevirt/issues/12333 Let me know if you still hit the issue. -- Stefano
Hi,
Thanks for responding back to me. I was trying these solutions, when I
realised that my /etc/apparmor.d/ directory already contains usr.bin.pasta.
I believe this is because I downloaded the latest package from the
launchpad. Using aa-status, it seems like ' /usr/bin/pasta.avx2 (1366)
pasta' is running in enforce mode. So I suspect there is no point trying to
do this over.
On Mon, May 12, 2025 at 11:36 AM Stefano Brivio
Hi Ayon,
On Sat, 10 May 2025 21:26:29 -0230 Ayon T
wrote: Hi,
I've been using pasta as a network driver for rootless docker and I've been running into a couple of issues for a while now. I hope this is where I can find some help troubleshooting.
The issue is that when I use pasta as the network driver as opposed to slirp4netns, I'm unable to access the internet through rootless docker or use ping (or traceroute) through its containers. So if I run "docker pull <image-name>" I get a timeout error:
Using default tag: latest Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 10.0.2.3:53: read udp 169.254.2.1:58905 ->10.0.2.3:53: i/o timeout
I'm running pasta version 0.0~git20250217.a1e48a0-1 on Ubuntu 24.04.2 LTS with docker v27.3.1 build ce12230.
I suspect you might be hitting this:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2077158
...which is fixed on Ubuntu 24.10 and later versions. As a workaround, I guess you can create the AppArmor profile for pasta manually, from:
https://passt.top/passt/tree/contrib/apparmor/usr.bin.pasta
or set /proc/sys/kernel/unprivileged_userns_apparmor_policy to 0, see also:
https://github.com/kubevirt/kubevirt/issues/12333
Let me know if you still hit the issue.
-- Stefano
On Mon, 12 May 2025 12:18:17 -0230
Ayon T
Hi,
Thanks for responding back to me. I was trying these solutions, when I realised that my /etc/apparmor.d/ directory already contains usr.bin.pasta. I believe this is because I downloaded the latest package from the launchpad.
...wait, so it's not 0.0~git20250217.a1e48a0-1 anymore? What version of passt are you using now? And what version of rootlesskit are you running? Does it contain this fix: https://github.com/rootless-containers/rootlesskit/pull/458 it's not directly related to your issue, but it changes the behaviour significantly. I don't remember how you would pass pasta options through moby / rootlesskit, but ideally you should try running pasta with --debug and --log-file. Another important bit of information would be if container connectivity works with an existing container (on 'docker run', not 'docker pull'), and, if it doesn't, whether pasta is running (check with 'ps ax') while the container is running. -- Stefano
Hi,
I'm sorry for the delayed response. No, I am still using
0.0~git20250217.a1e48a0-1. I just meant that I had not used apt for
installing passt.
I had an upgrade planned to Ubuntu 24.10 and after that upgrade, my
connections to port 53 are being refused when I'm using pasta, leaving me
unable to use a DNS resolver. I'm not sure why this is. It works fine with
the default network driver.
This is not the issue I contacted you with and that's why I'm trying to
figure out why this is happening myself (albeit with little luck).
Regards,
Ayon
On Mon, May 12, 2025 at 12:29 PM Stefano Brivio
On Mon, 12 May 2025 12:18:17 -0230 Ayon T
wrote: Hi,
Thanks for responding back to me. I was trying these solutions, when I realised that my /etc/apparmor.d/ directory already contains usr.bin.pasta. I believe this is because I downloaded the latest package from the launchpad.
...wait, so it's not 0.0~git20250217.a1e48a0-1 anymore? What version of passt are you using now?
And what version of rootlesskit are you running? Does it contain this fix:
https://github.com/rootless-containers/rootlesskit/pull/458
it's not directly related to your issue, but it changes the behaviour significantly.
I don't remember how you would pass pasta options through moby / rootlesskit, but ideally you should try running pasta with --debug and --log-file. Another important bit of information would be if container connectivity works with an existing container (on 'docker run', not 'docker pull'), and, if it doesn't, whether pasta is running (check with 'ps ax') while the container is running.
-- Stefano
Hi Ayon,
On Tue, 20 May 2025 12:09:46 -0230
Ayon T
Hi,
I'm sorry for the delayed response. No, I am still using 0.0~git20250217.a1e48a0-1. I just meant that I had not used apt for installing passt.
...where did you take that package from, though? If it's something like alvistack (https://github.com/alvistack/passt-top-passt/), there might be other patches or modified / missing AppArmor profiles, and I can't really look into that as well (I already maintain official packages, at least for Debian).
I had an upgrade planned to Ubuntu 24.10 and after that upgrade, my connections to port 53 are being refused when I'm using pasta, leaving me unable to use a DNS resolver. I'm not sure why this is. It works fine with the default network driver.
This is not the issue I contacted you with and that's why I'm trying to figure out why this is happening myself (albeit with little luck).
I would suggest to start passing the --pcap option to pasta, say: podman run --net=pasta:--pcap,/tmp/port53.pcap ... and then have a look at the resulting packet capture (with Wireshark / tshark, for example). As we keep fixing bugs, and we fixed quite a lot of things with UDP flows since February, an updated package, or even a build from source, (git clone git://passt.top && cd passt && make && sudo make install) might be worth a try. It takes a few seconds to build / install, and can be removed cleanly with 'sudo make uninstall'. -- Stefano
Hi, I have managed to fix the new connection refusal problem I was struggling with. Apparently my unprivileged port start setting had changed after the upgrade, even though it was set correctly in /etc/sysctl.conf. I fixed it by adding an entry in /etc/sysctl.d/. And what version of rootlesskit are you running? Does it contain this
fix:
https://github.com/rootless-containers/rootlesskit/pull/458
it's not directly related to your issue, but it changes the behaviour significantly.
To answer your questions, I'm using v2.3.1, which, I assume, includes this fix.
Another important bit of information would be if container connectivity works with an existing container (on 'docker run', not 'docker pull'), and, if it doesn't, whether pasta is running (check with 'ps ax') while the container is running.
I used docker exec to get into the containers that are already running and
I cannot ping/traceroute from the containers, but I can, for instance, use
wget google.com and download the webpage. pasta is running, checked using
ps ax.
...where did you take that package from, though?
I installed it using the deb package in
https://launchpad.net/ubuntu/+source/passt.
I know you have been asking me to run pasta with arguments with docker, but
I'm not sure how to do this (pardon my inexperience). I use an
override.conf file to set the default network and port driver of docker,
and that's how I use pasta with docker. I have tried looking up how to do
it in a different way that gives me more control over the arguments that go
in, but I haven't been able to find it. Could you guide me regarding this
or point me to a resource?
Thanks and regards,
Ayon
On Tue, May 20, 2025 at 1:26 PM Stefano Brivio
Hi Ayon,
On Tue, 20 May 2025 12:09:46 -0230 Ayon T
wrote: Hi,
I'm sorry for the delayed response. No, I am still using 0.0~git20250217.a1e48a0-1. I just meant that I had not used apt for installing passt.
...where did you take that package from, though? If it's something like alvistack (https://github.com/alvistack/passt-top-passt/), there might be other patches or modified / missing AppArmor profiles, and I can't really look into that as well (I already maintain official packages, at least for Debian).
I had an upgrade planned to Ubuntu 24.10 and after that upgrade, my connections to port 53 are being refused when I'm using pasta, leaving me unable to use a DNS resolver. I'm not sure why this is. It works fine with the default network driver.
This is not the issue I contacted you with and that's why I'm trying to figure out why this is happening myself (albeit with little luck).
I would suggest to start passing the --pcap option to pasta, say:
podman run --net=pasta:--pcap,/tmp/port53.pcap ...
and then have a look at the resulting packet capture (with Wireshark / tshark, for example).
As we keep fixing bugs, and we fixed quite a lot of things with UDP flows since February, an updated package, or even a build from source, (git clone git://passt.top && cd passt && make && sudo make install) might be worth a try.
It takes a few seconds to build / install, and can be removed cleanly with 'sudo make uninstall'.
-- Stefano
On Fri, 23 May 2025 00:51:25 -0230
Ayon T
I know you have been asking me to run pasta with arguments with docker, but I'm not sure how to do this (pardon my inexperience). I use an override.conf file to set the default network and port driver of docker, and that's how I use pasta with docker. I have tried looking up how to do it in a different way that gives me more control over the arguments that go in, but I haven't been able to find it. Could you guide me regarding this or point me to a resource?
Apologies for the delay. It looks like you need to rebuild rootlesskit with any option you want to add, here: https://github.com/rootless-containers/rootlesskit/blob/e83d7635183e1125798b... because there's currently no convenient command-line mechanism like the one implemented by Podman, here: https://github.com/containers/common/blob/5a4ca2d5d35571556f6e7d1d5f024c19dc... I guess it would be nice to implement something similar, but I'm not really familiar with rootlesskit otherwise. An alternative could be to use a trivial wrapper at /usr/local/bin/pasta, a simple script doing: -- #!/bin/sh /usr/bin/pasta $@ --whatever-additional-option-here -- -- Stefano
participants (3)
-
Ayon T
-
David Gibson
-
Stefano Brivio