canonical / canonical/multipass
Fresh install on Windows does not work (UTF-8 handling?)
- Dominant language
- C++
- Stars
- 9.2k
- Forks
- 829
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 45
Description
**Describe the bug**
I've installed Multipass on a Windows 11 Pro edition, following the three steps from the documentation.
Installation went well, but after restart, doing anything with the client is prevented.
For the CLI, all commands return the following error:
```
[error] [client] Caught an unhandled exception: failed to open file 'C:/Users/Céline/AppData/Local/multipass-client-certificate/multipass_cert_key.pem': No such file or directory(2)
```
For the GUI, the app is stuck on "Waiting for daemon..."
**To Reproduce**
How, and what happened?
1. Just install Multipass. Follow the given steps.
2. Then for instance, run `multipass --version`, or `multipass list`.
**Expected behavior**
What did you expect to happen?
That the program would give the installed version, or tell me that I didn't have any instance.
**Logs**
Please provide logs from the daemon, see [Access logs](https://canonical.com/multipass/docs/stable/how-to-guides/troubleshoot/access-logs/) on where to find them on your platform.
[multipass.txt](https://github.com/user-attachments/files/31797027/multipass.txt)
**Additional info**
- OS: Microsoft Windows 11 Pro (10.0.26200 Build 26200)
- CPU architecture or model: x64
- `multipass version`: does not work, but from multipass.gui.exe properties: 1.16.3
- `multipass info`: does not work
- `multipass get local.driver`: does not work.
**Additional context**
I tried to locate the missing file on my machine, then realized that the application had generated some additional folder on my machine: `C:\Users\Céline` (my username is Céline). I know it comes from Multipass, because its only content is this: C:\Users\Céline\AppData\Local\multipass-client-certificate`.
Contributor guide
Research direction
Start by reproducing a fresh Windows 11 installation with a username containing “é”, then inspect the generated client-certificate path and the attached logs. The fix is done when the CLI commands and GUI connect after installation and the certificate path preserves the username correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 62/100