`ls -la` chokes on absolute symlinks in WSL on Windows
Open
Nobody has claimed this yet.
U - ls
- Dominant language
- Rust
- Stars
- 24.1k
- Forks
- 2k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 365
Description
When trying to list my WSL root directory on Windows, coreutils stumbles upon /sbin when listing the WSL root dir using ls -la:
❯ .\target\release\coreutils.exe ls -la //wsl.localhost/NixOS/
ls: unknown io error: '//wsl.localhost/NixOS/sbin', 'Os { code: 1, kind: Uncategorized, message: "Unzulässige Funktion." }'
total 2724468
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:38 .
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:38 ..
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:38 bin
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:38 dev
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:38 etc
drwxrwxrwx 1 somebody somegroup 0 May 19 2025 home
-rwxrwxrwx 1 somebody somegroup 2724464 Apr 24 2025 init
drwxrwxrwx 1 somebody somegroup 0 Jun 28 2025 lib
drwxrwxrwx 1 somebody somegroup 0 Dec 18 12:36 lib64
drwxrwxrwx 1 somebody somegroup 0 May 19 2025 lost+found
drwxrwxrwx 1 somebody somegroup 0 May 19 2025 mnt
drwxrwxrwx 1 somebody somegroup 0 Jan 1 1970 nix
drwxrwxrwx 1 somebody somegroup 0 Oct 21 12:11 opt
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:38 proc
drwxrwxrwx 1 somebody somegroup 0 Jun 13 2025 root
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:40 run
lrwxrwxrwx 1 somebody somegroup 4 Aug 10 16:59 sbin
drwxrwxrwx 1 somebody somegroup 0 Jan 1 1970 srv
drwxrwxrwx 1 somebody somegroup 0 Feb 1 13:44 sys
drwxrwxrwx 1 somebody somegroup 0 Feb 2 08:28 tmp
drwxrwxrwx 1 somebody somegroup 0 Oct 20 10:23 usr
drwxrwxrwx 1 somebody somegroup 0 Oct 21 17:18 var
(Translation note: I guess the error is ERROR_INVALID_FUNCTION and its English message should be "Incorrect function.")
Note that /sbin is a symlink to /bin. GNU coreutils inside WSL:
❯ ls -la /sbin
lrwxrwxrwx 1 root root 4 Aug 10 16:59 /sbin -> /bin
PowerShell's `Get-ChildItem` handles this a bit more gracefully.
❯ Get-ChildItem \\wsl.localhost\NixOS
Directory: \\wsl.localhost\NixOS
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 01.02.2026 13:38 bin
d---- 01.02.2026 13:38 dev
d---- 01.02.2026 13:38 etc
d---- 19.05.2025 21:38 home
d---- 28.06.2025 20:59 lib
d---- 18.12.2025 12:36 lib64
d---- 19.05.2025 21:25 lost+found
d---- 19.05.2025 21:38 mnt
d---- 01.01.1970 01:00 nix
d---- 21.10.2025 12:11 opt
d---- 01.02.2026 13:38 proc
d---- 13.06.2025 12:43 root
d---- 01.02.2026 13:40 run
d---- 01.01.1970 01:00 srv
d---- 01.02.2026 13:44 sys
d---- 02.02.2026 09:00 tmp
d---- 20.10.2025 10:23 usr
d---- 21.10.2025 17:18 var
----- 24.04.2025 01:34 2724464 init
l---- 10.08.2025 16:59 4 sbin ->
However, even `Get-ChildItem` can't magically follow that symlink either.
❯ Get-ChildItem \\wsl.localhost\NixOS\bin
Directory: \\wsl.localhost\NixOS\bin
Mode LastWriteTime Length Name
---- ------------- ------ ----
l---- 01.02.2026 13:38 76 bash ->
l---- 01.02.2026 13:38 82 init ->
l---- 01.02.2026 13:38 67 login ->
l---- 01.02.2026 13:38 75 mount ->
l---- 10.08.2025 17:02 5 mount.drvfs ->
----- 01.02.2026 13:38 423 nixos-wsl-recovery
l---- 01.02.2026 13:38 62 sh ->
l---- 19.05.2025 21:38 5 wslinfo ->
l---- 01.02.2026 13:38 5 wslpath ->
❯ Get-ChildItem \\wsl.localhost\NixOS\sbin
Directory: \\wsl.localhost\NixOS
Mode LastWriteTime Length Name
---- ------------- ------ ----
l---- 10.08.2025 16:59 4 sbin ->
❯ Get-ChildItem \\wsl.localhost\NixOS\sbin\sh
Get-ChildItem: Cannot find path '\\wsl.localhost\NixOS\sbin\sh' because it does not exist.
❯ Get-ChildItem \\wsl.localhost\NixOS\bin\sh
Directory: \\wsl.localhost\NixOS\bin
Mode LastWriteTime Length Name
---- ------------- ------ ----
l---- 01.02.2026 13:38 62 sh ->
So a fix for this could be IMO that ls -la won't show an error, but will somehow be smart and not try to follow that symlink, so that the result is similar to the native Windows tooling?
Coreutils / Windows / WSL versions
❯ .\target\release\coreutils.exe --version && git describe
coreutils 0.6.0 (multi-call binary)
0.5.0-771-g61da637d5
❯ Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, WindowsVersion
OsName OsVersion OsBuildNumber WindowsVersion
------ --------- ------------- --------------
Microsoft Windows 11 Pro 10.0.26200 26200 2009
❯ wsl --version
WSL-Version: 2.5.7.0
Kernelversion: 6.6.87.1-1
WSLg-Version: 1.0.66
MSRDC-Version: 1.2.6074
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.26200.7705
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing ls -la //wsl.localhost/NixOS/ with the provided WSL and Windows versions, then trace how ls handles the absolute /sbin symlink and the resulting Windows error. Done means the command no longer reports an error for this entry and its output follows the expected behavior described in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100