Replies: 1 comment
-
So if anyone have this issue in the future, the reason for the rootful example not working is because netavark doesn't create the firewall rules that are needed for the example to work, for networks that are created with the flag --internal by design.
And get the result I get when running a container rootless. Note that the option no_default_route is only possible in versions of netavark >= 1.7.0 Edit: Actually even tho accessing the published port from localhost works, it doesn't work if you try to access it from the outside, so the problem is still not solved as with the rootless example, it is possible to access the container from the outside. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
So if I run the example below (rootless):
I get the default nginx html page from curl, so the published port works. But if I do the above but as root, the curl command doesn't show any result and just hangs until I manually stop it.
When doing it as root, if I check the command:
I can see that there isn't any rule for the port that was published but yet I can see via
ss -lt
that there is something listening in the port8080
.Also (in the rootful example) if I try to curl the container internal ip
curl 10.89.0.2:80
I get the expected nginx default html.I'm confused about what is the expected result, being able to publish ports from a container in a network created with the --internal flag like it's possible in the rootless example, being able to do it but without actually working like expected in the rootful one or both since they use different network backends and they respond differently to the --internal network tag?
Thank you for your help.
Beta Was this translation helpful? Give feedback.
All reactions