Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Obtention d'un accès refusé en essayant de monter un VHDX dans WSL sous Windows 11

ayi

J’ai créé un nouveau VHDX via le gestionnaire de disques, et j’essaie de le monter dans WSL2 (version 1.0.3), en exécutant la commande suivante :
<pre><code class="lang-auto">wsl -d Ubuntu-22.04 --mount --vhd D:\wsl2\wsl2-drive.vhdx --bare

</code></pre>
Cela échoue avec :
<pre><code class="lang-auto">Failed to attach disk '\?\D:\wsl2\wsl2-drive.vhdx' to WSL2: Access is denied.
Error code: Wsl/Service/AttachDisk/MountVhd/E_ACCESSDENIED

</code></pre>
Choses que j’ai essayées sans que cela change quoi que ce soit :
<ul>
<li>
L’exécuter depuis un PowerShell élevé
</li>
<li>
Créer un VHD au lieu d’un VHDX
</li>
<li>
Omettre <code>--bare</code>
</li>
<li>
Omettre <code>-d Ubuntu-22.04</code>
</li>
<li>
Avoir le VHDX dans différents états :
</li>
<li>
“Not Initialized / Unallocated” : l’état après la création dans le gestionnaire de disques
</li>
<li>
Choisir ‘Initialize disk’ dans le Gestionnaire de disques
</li>
<li>
Créer une partition (mais cela semble incorrect, puisqu’elle ne devrait pas être en NTFS pour Linux ?)
</li>
<li>
Le détacher complètement dans le Gestionnaire de disques
</li>
</ul>

ayi_2

Résolu via les commentaires, donc transfert des informations dans une réponse (avec quelques informations supplémentaires).
Les messages d’erreur WSL (relativement) récents ont été utiles dans ce cas. Le <code>Wsl/Service/AttachDisk/MountVhd/E_ACCESSDENIED</code> indiquait un problème de permissions d’un certain type.
Normalement, d’après ce que je peux constater, un fichier <code>.vhdx</code> créé via le Gestionnaire de disques sera possédé par le groupe Administrateurs local. Dans la plupart des cas, l’utilisateur local qui a installé et exécute WSL est membre de ce groupe, donc il n’y a pas de problèmes de permissions.
Cependant, dans ce cas, cela ne semble pas être le cas, puisque le changement de propriétaire du <code>.vhdx</code> a finalement résolu l’erreur <code>ACCESSDENIED</code>.
Quelques éléments supplémentaires :
<ul>
<li></li>
</ul>
Le disque virtuel doit être détaché du Gestionnaire de disques (Clic droit → Détacher le VHD) sinon l’erreur suivante se produira :
<pre><code class="lang-auto">Failed to attach disk '<path_to>\wsl2-drive.vhdx' to WSL2: The process cannot access the file because it is being used by another process.
Error code: Wsl/Service/AttachDisk/MountVhd/0x80070020

</code></pre>
<ul>
<li></li>
</ul>
Je recommande personnellement de créer le <code>.vhdx</code> depuis un compte PowerShell administratif en utilisant :
<pre><code class="lang-auto">new-vhd -Dynamic -SizeBytes 100gb -BlockSizeBytes 1mb -path <path_to>/<name>.vhdx

</code></pre>
La taille de bloc s’avère assez importante pour la vitesse de croissance du disque dynamique. La taille de bloc de 1 Mo est celle que WSL utilise pour ses disques virtuels intégrés.
<ul>
<li></li>
</ul>
Également, <code>--bare</code> est requis tant qu’il n’y a pas de système de fichiers sur le lecteur que WSL peut gérer. Votre prochaine étape sera de créer un système de fichiers sur ce disque virtuel depuis l’intérieur de WSL. Comme mentionné dans la <a href="https://learn.microsoft.com/en-us/windows/wsl/wsl2-mount-disk#attaching-the-disk-without-mounting-it">documentation WSL</a>, utilisez <code>lsblk</code> pour identifier le disque nouvellement monté.
Ce n’est pas une mauvaise idée de s’assurer complètement que vous formatez le bon périphérique en démontant, <code>lsblk</code>, puis remonter et <code>lsblk</code> à nouveau. Le nouveau périphérique sera évident dans ce cas. Bien entendu, une taille de disque unique est également un moyen valide de l’identifier.
Une fois le périphérique identifié, vous utiliserez quelque chose comme :
<pre><code class="lang-auto">sudo mkfs.ext4 /dev/<device> # e.g. sde

</code></pre>
<ul>
<li></li>
</ul>
Après avoir créé un système de fichiers sur le périphérique, tant que le système de fichiers est reconnu par WSL2 (<code>ext4</code>, <code>btrfs</code>, et probablement quelques autres), vous pouvez omettre l’option <code>--bare</code> pour les montages futurs.
À ce stade, c’est une bonne idée de passer à l’utilisation de <code>--name <name></code> afin que la partition/le système de fichiers soit monté à un emplacement connu. Par défaut, ce sera <code>/mnt/wsl/<name></code>.
<ul>
<li></li>
</ul>
Le <code>-d Ubuntu-22.04</code> dans ce cas est un no-op. Je suis un peu surpris que cela ne génère pas d’erreur, mais le périphérique est toujours monté dans toutes les distributions, que vous spécifiiez une distribution avec <code>wsl -d</code> ou non.