Immutable attribute on resolv.conf results in complications
Greenlander92 opened this issue · comments
I intended to use this as a VPN container on my unraid server to route the network traffic of specific containers right through is.
Apparently as soon as the NordVPN client connects to a server it will add the immutable attribute to the resolv.conf containing the DNS addresses and removes it after disconnecting again. Therefor I am not even able to update a your container from dockerhub with an active connection since docker can't remove the current build.
Removing the immutable attribute from the file with
chattr -i resolv.conf
fixes that issue.
On top of that I was not able to route any container through the VPN one since they all try and chown the resolv.conf which is forbidden and results in an error:
/usr/bin/docker: Error response from daemon: chown /var/lib/docker/containers/0149d4a878eb17d41e18ea74b519201007290b3b66248674890fef7f704cad7f/resolv.conf: operation not permitted.
So I wonder how you handle this issue? Does it actually apply to anyone but me?
Not entirely sure what you are trying to accomplish, can you please elaborate a little more ?
- Setting your 'own' DNS servers can be done using the DNS environment variables
- Routing other containers through this VPN container is as easy as setting the network_mode of the other containers to service:<name of your vpn container>
Sorry if I wasn't clear enough.
I just want to route other containers through this VPN one. And I know how to accomplish it.
The system I try to run this on is my Unraid server at home. But every time I set the network settings of a 2nd container to be routed through the VPN one I recieve the error from the 2nd container about not being able to chown the resolv.conf from the VPN container.
Since the VPN client from nordvpn is already running this file is flaged as immutable so not even the root user can change it's content nor change it's permissions. Therfor the chown operation is not permitted and the container fails to start. This behaviour from nordvpn client setting the resolv.conf as immutable after the VPN connection has been established is well known.
So I wonder why none else encountered this problem.
Just try to run this container and try to edit the resolv.conf of the container after a connection has been established. You shouldn't be able to do any changes to it nor delete it.
I think it is actually unraid that has a chattr +i on your resolv.conf. This container is not doing any chattr'ing at all.
Sorry but are you actually reading what I'm writing? I said its the nordvpn client that sets the resolv.conf to immutable not the container using it. And Unraid is actually just running docker in the background with a fancy UI for the user isn't it? Maybe when I'm bored this weekend I'll try to recreate this on a clean linux vm with pure docker
I am reading your comments, that's why I am responding. Before I responded, I tested it. The resolv.conf used by the the container or the containers making use of the vpn container as exit route, is NOT made immutable by this container or the nordvpn binary on an Ubuntu 20.04 server. Are you running version 3.7.4 of this container ? The newer ones don't work (yet) and might have some new functionality that does do some locking on resolv.conf.
Well I was running the latest version from dockerhub so I guess thats 3.8.5
Did I misread the desciptions somewhere that versions above 3.7.4 aren't stable? Maybe you can confirm this behaviour with the latest build
hello - I am facing exactly the same issue than Greenlander92...
I also pulled version 3.7.4 these days and it's the same situation
hello - I am facing exactly the same issue than Greenlander92...
are you trying to use this in unraid aswell? or just plain docker?
plain docker.. debian - I also needed to set privileged=true to have the container works.
without privileged no more immutable issues but the container doe not work with : "[Error] disabling IPv6: sysctl: setting key "net.ipv6.conf.all.disable_ipv6": Read-only file system"
Ok so I did some test on Debian 10 and Ubuntu 20 stock with docker...
with the latest version >3.7.4 to have it works you need privileged and then immutable resolv.conf.
with the version <= 3.7.4 you do not need privileged and it works with non immutable issues
Thanks @lebrou34.
I too have been facing the same issues, and pinning back to nordvpn version 3.7.4 and removing priviledged has stopped me hitting the immutable resolv.conf issues.
Having similar issues with Debian 10 and docker 19.03.13. Getting errors such as:
Cannot start service nordvpn: failed to write unhaltered resolv.conf file content when setting up dns for sandbox 0e500374005b78ea512d15d596aaaf6f7a6a36b16da8141cc2accd00ddb64a20: open /var/lib/docker/containers/c509d5ed72a8684c352a7c8b27ab094abdab9d19a0cde31b2fc7c68de2362e57/resolv.conf: operation not permitted
I'm not seeing the issue running this container, but can confirm that I am definitely seeing the issue with resolv.conf being marked immutable affecting termination of the container -- to the point that docker daemon can't remove it until I manually clear the flag with chattr.
There is no other immutable resolv.conf on the system - the only one present is in the container itself.
Looks like this is all tied to the 'kill switch' support in nordvpn client.
Same issue for me. I'm having to run the following when updating:
find /var/lib/docker/containers -iname resolv.conf -exec chattr -i -a {} \;
Same issue for me on fedora 33 + vanilla docker-ce.
First container create was fine but on next container restart error
Cannot restart container 19b7d00c224cdbfb585db927c59eb8bae712265fd0eeb54c1b0ea405126a33ba: failed to write unhaltered resolv.conf file content when setting up dns for sandbox 223459f475e6ce1c8f46554f895c4852cef5f6bdc9ad0189234a4b19b6bee514: open /var/lib/docker/containers/19b7d00c224cdbfb585db927c59eb8bae712265fd0eeb54c1b0ea405126a33ba/resolv.conf: operation not permitted
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.