WSL: datasource fails to find user-data if Windows username contains non-ASCII chars

[cnihelton]

Bug report

Windows has very few restrictions for a valid user name, and the user profile folder is by default derived from the user name, so having non-ASCII user names is valid even in the west side of the world. Even emojis are allowed! How exactly those upper characters are encoded depends on the system configuration. Legacy programs like the famous cmd.exe by default relies on ANSI code pages, which are tricky to handle because the meaning of a code point depends on the host system generating it, the parsing program needs to know what the active code page is to interpret text correctly. WSL environments are generally configured with UTF-8 encoding, which is compatible in the ASCII range only. Thus getting a path from cmd.exe and using it in Linux requires consideration about the decoding. cmd.exe supports enconding its output with UTF-16LE if invoked with the /u command line flag, which is more predictable to decode than ANSI code pages so we should use that instead.

Steps to reproduce the problem

• Have a Windows user name with special (non-ascii) characters
• Create a default.user-data file at the expected location
• Initialize a WSL instance with cloud-init (such as from Ubuntu-24.04)

Expected cloud-init to find the user data and apply it.
What happens instead is that the user profile folder is not found, so the user data file can't be found either.

Environment details

• Cloud-init version:
• Operating System Distribution:
• Cloud provider, platform or installer type:

cloud-init logs

In the log below the Windows user name is João Martín😁 and thus the user profile folder is at C:\Users\João Martín😁.

ds-identify.log:

[up 2.13s] ds-identify 
policy loaded: mode=search report=false found=all maybe=none notfound=disabled
/etc/cloud/cloud.cfg.d/99_wsl.cfg set datasource_list: [WSL, NoCloud]
WARN: No dmidecode program. Cannot read sys_vendor.
WARN: No dmidecode program. Cannot read board_name.
WARN: No dmidecode program. Cannot read chassis_asset_tag.
WARN: No dmidecode program. Cannot read product_name.
WARN: No dmidecode program. Cannot read product_serial.
WARN: No dmidecode program. Cannot read product_uuid.
DMI_PRODUCT_NAME=error
DMI_SYS_VENDOR=error
DMI_PRODUCT_SERIAL=error
DMI_PRODUCT_UUID=error
PID_1_PRODUCT_NAME=unavailable
DMI_CHASSIS_ASSET_TAG=error
DMI_BOARD_NAME=error
FS_LABELS=
ISO9660_DEVS=
KERNEL_CMDLINE=initrd=initrd.img WSL_ROOT_INIT=1 panic=-1 nr_cpus=8 hv_utils.timesync_implicit=1 console=hvc0 debug pty.legacy_count=0 WSL_ENABLE_CRASH_DUMP=1
VIRT=wsl
UNAME_KERNEL_NAME=Linux
UNAME_KERNEL_VERSION=#1 SMP PREEMPT_DYNAMIC Mon Apr 21 17:08:54 UTC 2025
UNAME_MACHINE=x86_64
DSNAME=
DSLIST=WSL NoCloud
MODE=search
ON_FOUND=all
ON_MAYBE=none
ON_NOTFOUND=disabled
pid=33 ppid=17
is_container=false
No .cloud-init directories found in /mnt/c/Users/Jo�o Mart�n??
No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1]
[up 2.25s] returning 1

Fixing ds-identify with something like:

WSL_run_cmd() {
    local val="" exepath="$1"
    shift
    # Using the '/u' flag to enforce Unicode (UTF-16 LE), thus we need to iconv afterwards.
    _RET=$(/init "$exepath" /u /c "$@" 2>/dev/null | iconv -f UTF-16LE -t UTF-8)
}

Allows finding the user data, and then the datasource fails:

ds-identify.log

...
DSLIST=WSL NoCloud
MODE=search
ON_FOUND=all
ON_MAYBE=none
ON_NOTFOUND=disabled
pid=33 ppid=17
is_container=false
Found applicable user data file for this instance at: /mnt/c/Users/João Martín😁/.cloud-init/default.user-data
check for 'WSL' returned found
Found single datasource: WSL
[up 2.52s] returning 0

cloud-init.log

...
2026-02-05 12:56:56,097 - DataSourceWSL.py[DEBUG]: cloud-init user data dir /mnt/c/Users/Jo�o Mart�n??/.ubuntupro/.cloud-init doesn't exist.
...