DNS servers not retained in resolv.conf on Unraid reboot.

[p-funk]

My resolv.conf doesn't retain static entries when I cycle Unraid.  Oddly enough, resolv.conf.avahi retains it's settings.  Any help would be appreciated.

nas-diagnostics-20200501-1156.zip

[trurl]

Are you editing /etc/resolv.conf yourself or something? I think normally that information would come from Settings - Network Settings in the webUI.

 

The Unraid OS is in RAM. It is unpacked fresh from the archives on flash at each boot into RAM, and then settings from the webUI, which are stored on flash, are applied.

 

Only /boot (the flash drive), and /mnt (the mounted disks and user shares) persist.

 

Any change you make to /etc and other OS folders will not persist since the OS is in RAM and any changes you make outside the webUI that affects any of that are not retained.

 

If you have some special need that can't be handled with the normal configurations in the webUI, you can write a script to apply those changes, and use the User Scripts plugin to run the script at boot.

[p-funk]

Here are the contents of network.cfg.  The DNS servers are not applied when the server cycles.  The only hand editing done is after the server cycles and I confirm that the static entries defined do not exist in resolv.conf.
# Generated settings:
IFNAME[0]="br0"
BONDNAME[0]="bond0"
BONDING_MIIMON[0]="100"
BRNAME[0]="br0"
BRSTP[0]="no"
BRFD[0]="0"
BONDING_MODE[0]="1"
BONDNICS[0]="eth0"
BRNICS[0]="bond0"
PROTOCOL[0]="ipv4"
USE_DHCP[0]="no"
DHCP_KEEPRESOLV="yes"
IPADDR[0]="192.168.0.5"
NETMASK[0]="255.255.255.0"
GATEWAY[0]="192.168.0.1"
DNS_SERVER1="8.8.8.8"
DNS_SERVER2="8.8.4.4"
USE_DHCP6[0]="no"
DHCP6_KEEPRESOLV="no"
MTU[0]="9000"
SYSNICS="1"

[trurl]

5 minutes ago, p-funk said:

hand editing

What are you editing and how?

[p-funk]

nano -w /etc/resolv.conf.  Just to get it resolving.  Just a bandaid.

# Generated DNSv4 entries:
nameserver 8.8.8.8
nameserver 8.8.4.4
# Generated DNSv6 entries:

Edited May 1, 2020 by p-funk

[trurl]

Not sure I understand, or maybe you don't.

 

Any changes you make directly to an OS file will not survive reboot, because the OS is in RAM. When you reboot, the archives on flash, which are exactly as you originally downloaded them, are unpacked fresh into RAM. So any changes you made directly to any OS files before you reboot will not persist after reboot, since they are not part of those original archives which are unpacked into RAM.

 

If you need some changes like this, you have to reapply them each boot.

[p-funk]

I understand this file is in RAM and a manual edit will not persist.  However, I have configured this interface to use 8.8.8.8 and 8.8.4.4 in network.cfg (via network settings in the web gui) and these settings are not applied when the server boots.

[p-funk]

Here's a use case.  Any function that requires dns resolution from the Unraid OS fails.  For example, checking for any community apps times out, as does checking for docker updates.  This led me to investigate name resolution.  I headed straight for resolve.conf to check entries.  I saw none.  I double checked the network config in the web gui and saw the correct entries there.  Do these entries become nameservers in resolve.conf?  If not, where do they reside?  Either way, name resolution does not work for Unraid.  Thanks for looking at this.  It's driving me nuts.

[bonienl]

28 minutes ago, p-funk said:

Do these entries become nameservers in resolve.conf?

It is resolv.conf which is used to store DNS entries.

DNS servers you configure in the GUI under network settings.

The settings are stored on flash in the network.cfg file.

Upon reboot the network settings are read, and resolv.conf is populated with the DNS entries.

 

If this is not working for you, there is something amiss with your system.

Try starting in safe mode and see if this solves the issue.

 

[p-funk]

Same result in Safe-Mode (no plugins, no-gui).  Should I start making preparations to re-install?

[bonienl]

Post your diagnostics. See Tools -> Diagnostics

 

Looking at your earlier diagnostics.

I see the 'avahi' protocol overruling your DNS settings and use DNS server 192.168.0.1

I guess this is coming from your router. And perhaps it can be disabled on your router.

 

An alternative solution is to disable 'avahi' on your server.

You need to edit the flie /config/share.cfg on your flash device and set

shareAvahiEnabled="no"

Save the file and reboot your system.

Edited May 1, 2020 by bonienl

[p-funk]

See first post.

[bonienl]

2 minutes ago, p-funk said:

See first post.

Yeah, sorry missed that.

See my answer above.

[p-funk]

Nice!  That did the trick.  Before this fix, I wonder why my resolve.conf.avahi contained the correct nameserver entries.  Of course that is no longer being created, but weird none the less.  Thank you!

[Cau5tic]

Having the same issue (along with a few others) after upgrading to 6.9.0

Has anyone figured out why avahi isn't populating resolv.conf?
 

 

Edited March 5, 2021 by Cau5tic

[xxb]

Having the same issue, please fix, thanx

[velvet]

hi, are there any updates or a fix for this?

now I have exactly the same problem!

 

 

[Sidious]

On 3/30/2022 at 11:53 AM, velvet said:

hi, are there any updates or a fix for this?

now I have exactly the same problem!

 

 

Here is what I had to do to fix this after bashing my head on  my desk for a while.
1. nano /boot/config/network.cfg
Add in two DNS servers
DNS_SERVER1="1.1.1.1"
DNS_SERVER2="1.0.0.1"

Set the DNS servers to what ever your preferred DNS is.
Then save the changes.

2. nano /boot/config/share.cfg
Change shareAvahiEnabled from yes to no
Then save the changes.

Rebooted and everything is sticking and working as intended.

The major frustration was that I could not add in DNS servers from the UI when I set a Static IP it would always set IPv4 DNS Server assignment to Automatic the only way I could get that changes was to set DHCP and then switch it back to Static. But the changes in the DNS entries would never stay. As soon as you hit apply it reverted the IPv4 DNS assignment back to automatic.

Not sure why that is or if there was something that I was missing but the above fix works for me as of 17 JUNE 2022 @1408 PST

Edited June 17, 2022 by Sidious