Custom resolv.conf being replaced by generated file, even with comment removed.

[j-c-m]

• A brief description
  Custom /etc/resolv.conf overwritten, even when "# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line." is removed.

• Expected results
  Custom /etc/resolv.conf should not be overwritten when comment is removed.

• Actual results (with terminal output if applicable)
  Custom /etc/resolv.conf replaced with standard generated /etc/resolv.conf

• Your Windows build number
  1703 - OS Build 15063.138

[j-c-m]

If I remove /etc/resolv.conf - which was a symlink -> /run/resolvconf/resolv.conf it will not remove my custom /etc/resolv.conf.

I can't verify but is it possible that this behavior changed from 14.04 -> 16.04 so the symlink isn't being followed by WSL when checking for the comment?

[benhillis]

Did you modify /etc/resolv.conf or /run/resolvconf/resolv.conf?

[j-c-m]

If the /etc/resolv.conf symlink was in place it would implicitly only modify /run/resolvconf/resolv.conf - and changes would always be automatically overwritten as long as /etc/resolv.conf was a symlink.

[benhillis]

It looks like there is an issue that is causing the resolv.conf file to be regenerated each time an instance is launched. We are looking at ways to improve this experience.

[benhillis]

Sorry, did not mean to close.

[sunilmut]

Here is some more background. By default, bash.exe will auto-generate /etc/resolv.conf every time you launch bash.exe. Then it will try to keep it up to date with changes from Windows, when bash is running. We somehow screwed up the logic to stop-auto generation when you remove the first line. It looks like if you remove the first line, we stop auto-update of the file while bash is running, but forgot to disable the logic to auto-generate during bash launch. We do apologize for the inconvenience and as @benhillis mentions, we are looking to improve the experience here.

[bradley101]

The problem still persists in Insider Preview 16241.
I solved this issue by following steps

1. Delete /etc/resolv.conf
2. Make /etc/resolv.conf by vim/nano
3. Insert appropriate nameservers.
4. Done!

Logout and the again run bash on cmd

[benhillis]

@sunilmut is currently looking at this.

[sunilmut]

Thanks @bradley101. For this release (Fall Creators Update), we will have to live with the workaround you have pointed out, here. For next release, we will relook at the better support for other VPN solutions.

[lmayorga1980]

followed @bradley101 workaround and back in business.

[daghb]

Issue is still there in current Windows release

[ManuCasl]

followed @bradley101 and it works

[jvosper]

FTR this matter remains an issue as part of Win 10 Pro Build 17134.

That said, @bradley101 's solution worked for me on my Win 10 Ubuntu WSL provided I didn't reboot my PC. The resolv.conf content remained in tact after multiple open/closes of Ubuntu WSL and also after connecting/disconnecting to my VPN.

That said, following a system reboot the /run/resolvconf/resolv.conf is regenerated and thus in turn the symlinked /etc/resolv.conf file reflects this change.

Cheers.

[andrewr01]

This fella helped me out with this issue: https://grayson.sh/blogs/fixing-wsl-search-domains

[jvosper]

@andrewr01 that link to Kent Grayson's blog worked for me. Thanks for providing it!

I would say to anybody looking to employ Kent's solution that you may want to keep an original copy of the resolv.conf instead of moving it wholesale like his instructions promote. Otherwise, I appear to be good for now and will report back if anything comes up.

[gustavlasko]

How has this not yet been fixed?

[MrSleazy]

Can confirm. The file is still being overridden whenever bash.exe is executed. None of the proposed solutions worked for me.

[michaelklachko]

The workaround provided does not survive a reboot. Come on guys, it's been 3 years.

[jvosper]

@gustavlasko , @KevinSilvaQuintana , and @michaelklachko the workaround noted by @andrewr01 back on Feb 18, 2019 has persisted for me since I noted as much on Feb 19.

[jakethedev]

I feel like rm'ing a symlink and 'sudo cat content >> /etc/resolv.conf' should not be part of my daily workflow anymore, does anyone know if this is going to be fixed in the WSL 2 general release?

[Spongman]

how is this still not fixed? do you guys just not care any more?

[jakethedev]

Note: Since the last time I nuked the symlink and replaced the file, it's stuck, so this may have been fixed silently in an update that happened sometime this quarter. Thanks all!

[tonyvitonis]

None of the solutions work for me. Not ready for prime time.

[lostbg]

Once you edit the resolv.conf file, you can do:
sudo chattr +i /etc/resolv.conf - which will make the file immutable and won't be overwritten next time you start wsl.

[benhillis]

What many of you guys are likely running into, is /etc/resolv.conf is typically a symlink to a file that resides in a tmpfs mount (that will be recreated each time the instance is started).

root@BENHILL-DELL:/c/Users/benhill# readlink /etc/resolv.conf
../run/resolvconf/resolv.conf
root@BENHILL-DELL:/c/Users/benhill# mount | grep -i run
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)

I'd suggest deleting this symlink and replacing it with a regular file.

[unix-geek]

I followed the instructions given by /etc/resolv.conf and added to /etc/wsl.conf:

[network]
generateResolvConf = false

This does not seem to prevent /etc/resolv.conf from being auto-generated, regardless of whether or not it is a link to /var/run/resolvd/resolv.conf

I did try 'chattr +i /etc/resolv.conf' suggested by @lostbg and that caused /etc/resolv.conf to remain persistent, but that strikes me more as a "utilitarian dirty hack" rather than a solution, since I'm probably going to forget what I did, and then wonder why I can't edit resolv.conf in the future.

I totally get the behavior for new users who don't want to mess with their DNS settings, but either there needs to be a different solution, or at least the documented solution in the file should actually do what it says.

[brandonmreese]

None of the workarounds work for me either (my file will be overwritten on launch of bash.exe regardless of any of the suggested steps)

OS Build 19.041.329

[j-c-m]

This worked for me on WSL2 -

/etc/wsl.conf

[network]
generateResolvConf = false

Inside a wsl session -

sudo rm /etc/resolv.conf
# create your own /etc/resolv.conf
sudo vim /etc/resolv.conf

Immediately shutdown wsl, do not start another session until you execute from a windows command prompt.

wsl --shutdown

[adipose]

The shutdown was what I was missing. Maybe they should update that message to be useful.

[j-c-m]

Yes, it doesn't appear to reload the wsl.conf file until wsl --shutdown, so if you start a new terminal before completely shutting down wsl it clobbers /etc/resolv.conf with a symlink to the auto-generated file.

[remiflament]

Indeed the wsl --shutdown command from the windows command line was successfull! Thank you @j-c-m

[stivo85]

This worked for me on WSL2 -

/etc/wsl.conf

[network]
generateResolvConf = false

Inside a wsl session -

sudo rm /etc/resolv.conf
# create your own /etc/resolv.conf
sudo vim /etc/resolv.conf

Immediately shutdown wsl, do not start another session until you execute from a windows command prompt.

wsl --shutdown

This solution works for me, thanks!

[Johawila]

Once you edit the resolv.conf file, you can do:
sudo chattr +i /etc/resolv.conf - which will make the file immutable and won't be overwritten next time you start wsl.

I've been searching for a solution to this for ages, this did the trick for me! Thanks

[niilz]

First of all @j-c-m's suggestion also worked for me.

But! I did a silly mistake, that kept me struggling for a bit longer. So my here it is, just in case.

---

Make sure you also uncomment the [network] header.

So that the change in wsl.conf looks indeed like this:

[network]
generateResolvConf = false

And NOT like this

# [network]
generateResolvConf = false

[mehrdadnd]

I found this solution to work very well. Is important to shutdown WSL2 in a correct way so it accepts the changed settings.
do above or here settings. then shutdown WSL via command from cmd or powershell .

wsl.exe --terminate NAME_OF_YOUR_LINUX

and open a WSL one more time, this time the settings should be persisted as it supposed.

[seffyroff]

Behavior is slightly different than written above for me. I've added the correct entry to wsl.conf:

[network]
generateResolvConf = false

After wsl --shutdown then wsl -d Ubuntu-20.04 There is no symlink or any other kind of /etc/resolv.conf. I make a new one with the entries I want. DNS resolution starts working again properly.
On subsequent launch of wsl the /etc/resolv.conf is gone. It seems to be removed upon launch every time.

The only fix that has worked for me is chattr +i /etc/resolv.conf. That's treating the symptom rather than the cause though :/

[KatSteinke]

For me /etc/resolv.conf also resets despite having added the correct entry to wsl.conf, removing the symlink and creating my own resolv.conf, and it's not even just on restarting WSL or opening a new session - sometimes it seems to happen even when I leave the computer running overnight.
EDIT: now it's happened in the span of hours.

[mezhgano]

Algorithm that worked for me:

1. Add following to //etc/wsl.conf:

[network]
generateResolvConf = false

2. Remove symlink and create new resolv.conf:

sudo rm /etc/resolv.conf
sudo micro /etc/resolv.conf

3. Add following to resolv.conf:

nameserver 192.168.1.1 
# (or whatever DNS adress you need)

4. Shutdown WSL from Powershell:

wsl --shutdown

5. Start WSL session again just like usual and check if it helps

[liechtir]

when not generating the resolv.conf you risk to loose your network connectivty from WSL as soon as your IP changes on the host.
easiest way to mittigate that is to have in wsl.conf

[network]
generateResolvConf = **true**

this leads to a generated resolv.conf

and within your ~/.bashrc you add:
sudo bash -c 'echo "nameserver xxx.xxx.xxx.xxx" >> /etc/resolv.conf'

for every name server you want to have in there. Like this, every time you login, your additional network config is added to the resolv conf and all is fine, no more headache.

[mezhgano]

Thanks for the info, this looks more proper way to solve the issue.

[mezhgano]

@liechtir I gave it a try and it doesn't work the way i expected in my case. Reasons:

1. It does require root password every time i log in which is not comfortable.
2. Generated resolv.conf already have nameserver ip (172.25.16.1). It is Virtual Ethernet Adapter (WSL) ip, i don't know how it supposed to work this way, but it never works.
3. Then i echoing my nameserver as you mentioned, it leads to significant delay in name resolution, for example i use simple ping command and only after 5-6 seconds it start actually pinging. Maybe because it tries first (in my case broken) ip in a list of nameservers.

My DNS ip never changes, because it is ip of my home router, so for now, i decided to turn off autogenerate resolv.conf.
If i doing something wrong anybody please correct me.

[glasko-dp]

@benhillis How does this still not work consistently after 5.5 years?

[julian7]

@benhillis How does this still not work consistently after 5.5 years?

Since the file is regenerated when bash.exe starts, and it keeps the file updated while it runs (see #1350 (comment)), I'm not surprised that WSL is not stable. I mean, where the architects were, when this decision was made?

[mokonofua]

This worked for me on WSL2 -

/etc/wsl.conf

[network]
generateResolvConf = false

Inside a wsl session -

sudo rm /etc/resolv.conf
# create your own /etc/resolv.conf
sudo vim /etc/resolv.conf

Immediately shutdown wsl, do not start another session until you execute from a windows command prompt.

wsl --shutdown

Worked for me!!!