Quick fix
# One shot: assign a default user for the imported distro (restart the distro afterwards)
echo -e "[user]\ndefault=your-username" >> /etc/wsl.conf
Then terminate the distro and re-enter from Windows:
wsl --terminate <distro-name>
wsl -d <distro-name>
What you will run into
After wsl --export backup and wsl --import migration/reinstall, whoami inside WSL suddenly shows root: home directory, ssh keys and file ownership are all messed up.
To make it worse, <distro> config --default-user yourusername errors or does nothing — imported distros have no executable launcher, so that command does not apply to them.
Why this happens
The default user of a WSL distro is decided by two sources: the Store distro launcher's default user (what <distro> config --default-user changes), and /etc/wsl.conf [user] default=.
A distro installed via wsl --import has no executable launcher, so config --default-user does not work on it — the official docs say exactly that; the only route is wsl.conf.
The tar produced by wsl --export keeps /etc/wsl.conf inside the distro as-is: if the original distro never wrote [user] default=, nothing specifies a non-root user after import, so WSL starts as root by default.
That explains "it was fine before migration, root after": the problem is not the migration, it is the missing [user] section in the original config.
Deterministic takeaway: after import, whoami = root → first cat /etc/wsl.conf and check for a [user] section — if missing, add it and restart the distro;
config --default-user only works on Store-installed distros, trying it on an imported one is wasted effort.
Step by step
1. Confirm the current state — Must do
whoami # root = missing [user] config
cat /etc/wsl.conf
2. Write the [user] section — Must do
# The username must already exist (created with useradd or previously used)
echo -e "[user]\ndefault=your-username" >> /etc/wsl.conf
If a [user] section already exists, change only the default= line — don't append a duplicate section header.
3. Restart the distro to apply — Must do
# Run on the Windows side (not inside WSL)
wsl --terminate <distro-name>
wsl -d <distro-name>
wsl.conf is only read when the distro starts; without a restart the change does not take effect.
4. Store-installed distro (not imported) — By scenario
For a normally installed Ubuntu, either <distro> config --default-user <username> (PowerShell/CMD) or the same wsl.conf section works.
How to confirm it works
After re-entering, whoami prints the target username; wsl --user root still switches to root temporarily (--user is a one-shot override and does not change the default); home directory / ssh permissions are back to normal.
Other environments
| Environment | Note |
|---|---|
| Imported distro (wsl --import) | config --default-user is ineffective; wsl.conf only (stated in official docs) |
| Store-installed distro | <distro> config --default-user <user> works |
| One-shot switch | wsl -d <distro> -u <user> applies to that session only |
Symptom
$ whoami
root
$ ubuntu config --default-user myuser # imported distro: errors or no effect
Signature: normal user before migration/import, root after import; /etc/wsl.conf has no [user] section; config --default-user is ineffective on the imported distro.
Cause
The WSL start user is decided by the launcher's default user or /etc/wsl.conf [user] default=. Distros installed via wsl --import have no executable launcher, so config --default-user does not work; export preserves the original wsl.conf, and when the original config lacks a [user] section the imported distro starts as root.
Solution
whoami+cat /etc/wsl.confto confirm the missing[user]section;echo -e "[user]\ndefault=your-username" >> /etc/wsl.conf(the username must already exist);- Restart the distro from Windows with
wsl --terminate <distro-name>; - Re-enter and verify
whoami.
Verification Evidence
- Mechanism check: Microsoft official docs (basic-commands warning on
config --default-user+ wsl-config[user] default=), URLs in the evidence log; - Local comparison (2026-08-31): on this machine
whoami= root and/etc/wsl.confhas no[user]section, consistent with the mechanism; did not modify config to reproduce the fault (to avoid affecting the working environment);
Evidence details kept locally (2026-08-31)
Related canonicals
Read in order: precondition -> same root / same domain / related:
- Related (similar errors, different cause):
- WSL fails to register a distro (same domain: WSL distro lifecycle problems)
- WSL systemd not running (another wsl.conf pitfall: no effect without a distro restart)
Applicable tools (1)
This problem is linked from the tool pages below — reachable from either side.
wslSource & evidence
← Coding Agents & Terminal domain | Problem Catalog Experience | Facing another issue? Go to the Helpdesk