I looked into the issue myself.
What happens is that when you create a network namespace, you see /etc/resolv.conf
of the host machine unless you create explicitly /etc/netns/<namespace_name>/resolv.conf
, which will bind mount automatically to /etc/resolv.conf
when looked up inside the network namespace. Therefore, by simply creating that path, the resolv.conf
of the host won't be visibile any more on the network namespace, which will have its own resolv.conf
.
The manual page of ip netns
explains this:
For applications that are aware of network namespaces, the convention
is to look for global network configuration files first in
/etc/netns/NAME/ then in /etc/. For example, if you want a different
version of /etc/resolv.conf for a network namespace used to isolate
your vpn you would name it /etc/netns/myvpn/resolv.conf.
Ip netns exec automates handling of this configuration, file
convention for network namespace unaware applications, by creating a
mount namespace and bind mounting all of the per network namespace
configure files into their traditional location in /etc.
As far as updating resolv.conf
, dhclient
doesn't work in network namespaces out of the box when /etc/netns/<namespace_name>/resolv.conf
exists (on the other hand, when it doesn't exist, it will overwrite the resolv.conf
of the host machine, since it's the only one available, but that's not really desirable). As the error in the question above shows, what happens is that dhclient
prepares a temporary file with the new nameserver details in /etc/resolv.conf.dhclient-new.2740
and then tries to rename it as /etc/resolv.conf
. It generates an error because /etc/resolv.conf
is already bind-mounted and apparently mv
isn't allowed to do this trick.
In order to make dhclient
work in network namespaces, /sbin/dhclient-script
should be modified.
I removed this:
mv -f $new_resolv_conf /etc/resolv.conf
And replaced it with:
cat $new_resolv_conf > /etc/resolv.conf
rm -f $new_resolv_conf
Otherwise, dhcpcd
seems to do this job correctly.