WSL2 Cannot List Windows Drive Root Directories (Windows 11 Insider Build 26200)

# WSL2 Cannot List Windows Drive Root Directories (Windows 11 Insider Build 26200)

## Environment

- **WSL Version**: 2.6.1.0 (also tested with 2.3.26.0)
- **Kernel Version**: 6.6.87.2-1 (also tested with 5.15.167.4-1)
- **WSLg Version**: 1.0.66 (2.3.26: 1.0.65)
- **Windows Version**: 10.0.26200.6901 (Windows 11 Insider Canary Channel)
- **Linux Distribution**: Ubuntu 24.04.2 LTS (Noble Numbat)
- **Filesystem Type**: 9p (drvfs)

## Issue Description

`ls` command in WSL2 returns empty results when listing Windows drive root directories (e.g., `/mnt/c/`, `/mnt/d/`, `/mnt/f/`), but subdirectories can be accessed normally through absolute paths.

## Reproduction Steps

```bash
# 1. Navigate to mount point
cd /mnt/c

# 2. List directory contents - returns empty
ls
# (no output)

ls -la
# total 4
# drwxrwxrwx 1 root root 4096 Dec 26 09:08 .
# drwxr-xr-x 11 root root 4096 Dec 7 21:43 ..

# 3. But subdirectories work fine via absolute path
ls /mnt/c/Users
# Administrator All Users Default Default User Public

# 4. Windows commands can list the contents
cmd.exe /c "dir C:\ /b"
# .superId
# DrvPath
# inetpub
# ... (13 items total)
```

## Affected Drives

- [x] C drive (`/mnt/c/`) - root directory ls empty
- [x] D drive (`/mnt/d/`) - root directory ls empty
- [x] F drive (`/mnt/f/`) - root directory ls empty
- All other drives show the same behavior

**Note**: All subdirectories are accessible via absolute paths.

## Current Mount Information

### WSL 2.6.1.0 (before rollback)
```
C:\ on /mnt/c type 9p (rw,noatime,aname=drvfs;path=C:\;uid=1000;gid=1000;metadata;umask=22;fmask=11;symlinkroot=/mnt/,access=client,msize=65536,trans=fd,rfd=6,wfd=6)
```

### WSL 2.3.26.0 (after rollback)
```
C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=4,wfd=4)
```

## Configuration Files

### `/etc/wsl.conf` (original)

```ini
[boot]
systemd=true

[user]
default=BigBig

[automount]
enabled = true
root = "/mnt/"
options = "metadata,umask=22,fmask=11,cache=none"
mountFsTab = true
```

### `/etc/wsl.conf` (simplified - still doesn't work)

```ini
[boot]
systemd=true

[user]
default=BigBig

[automount]
enabled = true
root = "/mnt/"
```

## Troubleshooting Attempts

All attempts failed to resolve the issue:

| Solution | Result | Date |
|----------|--------|------|
| Modified `wsl.conf` with `cache=none` | ❌ Failed | 2025-12-26 |
| `wsl --shutdown` and restart | ❌ Failed | 2025-12-26 |
| Manual `umount` and `mount -t drvfs` | ❌ Failed | 2025-12-26 |
| Different mount options (uid/gid/metadata) | ❌ Failed | 2025-12-26 |
| **Rollback to WSL 2.3.26.0 (kernel 5.15.167.4)** | ❌ Failed | 2025-12-26 |
| Simplified `wsl.conf` (removed all mount options) | ❌ Failed | 2025-12-26 |
| Created new mount point without options | ❌ Failed | 2025-12-26 |
| Used root privileges for ls | ❌ Failed | 2025-12-26 |

### Rollback Test Details

```powershell
# Manually installed WSL 2.3.26.0
msiexec.exe /i wsl.2.3.26.0.x64.msi /qn
wsl --shutdown

# Verified version
PS> wsl --version
WSL 版本： 2.3.26.0
内核版本： 5.15.167.4-1

# Issue still persists
PS> wsl ls /mnt/c/
# (empty output)
```

## Technical Analysis

### Confirmed Working
- ✅ Subdirectories accessible via absolute paths (`/mnt/c/Users`, `/mnt/f/OneDrive`)
- ✅ Windows commands can list root directories (`cmd.exe /c "dir C:\"`)
- ✅ File system permissions appear correct (verified with `icacls`)

### Confirmed NOT Working
- ❌ `ls /mnt/c/` returns only `.` and `..`
- ❌ `sudo ls /mnt/c/` also returns empty
- ❌ Problem persists across WSL versions (2.6.1.0 and 2.3.26.0)
- ❌ Problem persists across kernel versions (6.6.87.2 and 5.15.167.4)

### Root Cause Hypothesis

This appears to be a **compatibility issue between Windows 11 Insider Build 26200.6901 and WSL's drvfs/9p filesystem** at the system call level:

1. The `readdir`/`getdents64` system call seems to return empty results for drive root directories
2. The issue is NOT caused by WSL kernel version (tested multiple versions)
3. The issue is NOT caused by mount configuration (tested multiple configurations)
4. Directory traversal works at subdirectory levels but fails at root level
5. inode lookup works (can access subdirectories), but directory enumeration fails at root

## Expected Behavior

`ls /mnt/c/` should list all files and directories in the Windows C: drive root, similar to:
```
.superId DrvPath inetpub PerfLogs Program Files Users Windows ...
```

## Actual Behavior

`ls /mnt/c/` returns empty (only shows `.` and `..`).

## Impact

- Users cannot list Windows drive root directories from WSL2
- Scripting and automation that relies on listing drive contents is broken
- Users on Windows 11 Insider builds are significantly affected

## Workaround

Until this is fixed, users can:
1. Access files via absolute paths (e.g., `/mnt/c/Users/...`)
2. Use Windows commands: `cmd.exe /c "dir C:\"` or `powershell.exe -Command "Get-ChildItem C:\"`
3. Create bash aliases:
```bash
alias lswin='powershell.exe -Command "Get-ChildItem | Select-Object -ExpandProperty Name"'
```

## Related Issues

- Possibly related to Windows Insider filesystem or security changes
- May be related to 9p protocol changes in recent Windows builds

## System Information

```
PS> wsl --version
WSL 版本： 2.6.1.0
内核版本： 6.6.87.2-1
WSLg 版本： 1.0.66
MSRDC 版本： 1.2.6353
Direct3D 版本： 1.611.1-81528511
DXCore 版本： 10.0.26100.1-240331-1435.ge-release
Windows 版本： 10.0.26200.6901

PS> wsl uname -a
Linux LAPTOP 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
```

---

**Thank you for looking into this issue!** This is a critical bug affecting Windows Insider users with WSL2.

Start by reproducing the empty listings with `ls /mnt/c/`, `ls /mnt/d/`, and `ls /mnt/f/` on the reported Windows and WSL versions, then compare root enumeration with access to paths such as `/mnt/c/Users`. No source file or test is named; done means root directory entries are listed while subdirectory access and the reported mount configurations continue to work.

Written by the indexing model from the issue text.