Why Proxmox Keeps Overwriting resolv.conf in Your LXC Container After Migration

You moved a site from an old VPS into a Proxmox LXC container, copied the filesystem across, and fixed /etc/resolv.conf so it points at the nameservers you actually want. Then the container restarts and the file is back to something else, usually whatever the Proxmox host uses. You edit it again, restart again, and the same thing happens. Nothing inside the container is doing this. Proxmox writes that file on purpose every time the container starts. Once you see where the write comes from and where the values come from, the fix is a choice rather than a fight. This comes up often after migrations because the old VPS treated /etc/resolv.conf as an ordinary file the guest owned. In an LXC container on Proxmox, the host considers part of that file its responsibility.

What happens to a container's files before it boots

A container is not a virtual machine. It has no kernel or bootloader of its own. It is a set of processes on the host kernel, isolated with namespaces, with a directory tree (the container's root filesystem) mounted as its /. That shared design means the host can reach into the container's filesystem before any process inside it runs. Proxmox uses that access. When you run pct start or click Start in the web UI, the start roughly goes like this:

Proxmox reads the container config at /etc/pve/lxc/<vmid>.conf.
It prepares the LXC config and calls LXC to start the container.
Before the container's init process starts, a Proxmox hook runs with the container's root filesystem mounted.
That hook detects the guest distribution and runs distro-specific setup code. The code writes the hostname, updates /etc/hosts, writes network configuration for the interfaces defined in Proxmox, and writes DNS settings into /etc/resolv.conf.
Only after that does the container's init (usually systemd) start and read those files like it would on any machine.

Your edit from inside the running container is a normal write to a normal file. It persists on disk until the next start, when step 4 overwrites it again. This is why a reboot of the container and a reboot of the host look the same from the container's point of view. Both go through the start path. A plain service restart inside the container does not.

Where Proxmox gets the nameservers it writes

The container config has two DNS-related options: nameserver and searchdomain. In the web UI they appear under the container's DNS settings. When they are set, Proxmox writes those values into the container's /etc/resolv.conf. When they are not set, Proxmox falls back to the host's own DNS configuration. That fallback is why the reset file often looks exactly like the host's /etc/resolv.conf. After a migration, the second case is the usual one. The container was created with DNS left at the default, the old VPS's resolv.conf came across with the filesystem, and Proxmox replaces it at the first start. Nothing looks wrong until something depends on the old nameservers, such as an internal resolver, a split-horizon zone, or a resolver that is allowed through a firewall when the host's resolver is not. You can confirm which case you are in from the host and from inside the container:

BASH

# On the Proxmox host: show DNS options for container 101 (no output means unset)
pct config 101 | grep -Ei 'nameserver|searchdomain'

# Inside the container: is resolv.conf a regular file or a symlink?
ls -l /etc/resolv.conf
cat /etc/resolv.conf

The ls -l check matters more than it looks. On many modern distributions, /etc/resolv.conf is not a plain file. It is a symlink into /run/systemd/resolve/ managed by systemd-resolved, or it is generated by resolvconf or a DHCP client. If that is the case, there may be two writers involved: Proxmox at start, and a service inside the container after boot. Before you blame Proxmox, check whether the file changes again a minute after boot, once services like systemd-resolved, NetworkManager, or a DHCP client have started.

Option one: configure DNS in Proxmox

If the container should use fixed resolvers, the cleanest fix is to tell Proxmox what you want and let it keep writing the file. The values live in the container config, show up in the UI, survive restarts, and travel with backups and migrations between Proxmox nodes.

BASH

# Set nameservers and search domain for container 101 (applied at next start)
pct set 101 --nameserver '192.0.2.53 192.0.2.54' --searchdomain 'example.internal'

# Restart the container so the setup step writes the new values
pct reboot 101

The addresses above are illustrative documentation addresses. Replace them with your real resolvers. Multiple nameservers go in one space-separated value. This approach fits most hosting setups. A support engineer looking at the container can see the DNS settings without logging in, and the settings stay correct when someone rebuilds the guest from a template. The trade-off is that DNS for the container is now managed outside the container. Anyone who only looks inside it may still try to edit resolv.conf by hand and be confused when the edit disappears.

Option two: tell Proxmox to leave the file alone

Sometimes the guest really should own its DNS. The container may run its own local resolver such as Unbound, use systemd-resolved with per-interface settings, or be managed by a configuration tool that expects to write resolv.conf itself. For those cases Proxmox has a per-file opt-out. It checks for an empty marker file named .pve-ignore.<filename> in the same directory as the file it would manage. If the marker exists, it skips that file. For resolv.conf, the marker goes inside the container at /etc/.pve-ignore.resolv.conf:

BASH

# Inside the container: stop Proxmox from managing /etc/resolv.conf
touch /etc/.pve-ignore.resolv.conf

The same pattern works for the other files Proxmox manages. /etc/.pve-ignore.hosts and /etc/.pve-ignore.hostname follow the same naming. The marker only affects the file it names, so Proxmox still sets the hostname and network config as usual. That is usually what you want. Turning off all guest setup with the unmanaged OS type in the container config is a much bigger switch, because it also stops Proxmox from writing network configuration. A few details are easy to miss:

The marker is checked at start, so it has no effect until the next container start. Fix the contents of resolv.conf first, then create the marker, then restart and confirm.
The marker lives in the container's filesystem. If you restore the container from an older backup or rebuild it from a template, the marker may be gone and the overwriting comes back.
If resolv.conf is a symlink managed by systemd-resolved, the marker stops Proxmox from touching it, but systemd-resolved still controls the contents. You then configure DNS through resolved's own settings, not by editing the file.

The trade-off mirrors option one. The guest is now the single source of truth, and the DNS fields in the Proxmox UI no longer describe what the container actually uses. That can confuse the next person who looks only at the host. A short note in the container's Notes field in Proxmox helps.

How to pick between them

A practical rule of thumb is to ask who should be able to change this container's DNS without logging in. If the answer is the people running the Proxmox node, set nameserver and searchdomain in the container config and leave resolv.conf to Proxmox. If the answer is whatever runs inside the guest, such as a local caching resolver, a config management agent, or an application stack that ships its own resolver setup, use the ignore marker and manage DNS inside the container. Avoid ending up with both. A common pattern after migrations is DNS values set in the Proxmox config and an ignore marker in the container that nobody remembers adding. The UI then shows one set of resolvers while the container quietly uses another. When DNS behaves oddly in a container, check four things in order: the pct config output, whether /etc/.pve-ignore.resolv.conf exists, whether resolv.conf is a symlink, and what the file contains after a full restart and a minute of uptime. Memory figures inside containers can be misleading for related reasons, covered in Why an LXC Container on Proxmox Shows the Host's Full RAM in free and top. In short, the overwrite is not a bug. It is Proxmox doing setup at the one moment it controls, before the container starts. Decide which side owns DNS, configure it on that side only, and the file will stop changing under you.