Input/Output Error when trying to cd into Windows Symlink directory points to a mapped network share

[BlackHoleFox]

Windows Build Version 10.0.16299.125

• What you're doing and what's happening: I am trying to cd into a symlink created in my user's documents folder (C:) that is linking to a network drive (Z:). The symlink is created successfully and works 100% from the Windows OS but whenever I try to cd into that folder under /mnt/c/Users/.../Documents/ in the Ubuntu instance it gives me the error -bash: cd: NetworkCodeDrive: Input/output error

• What's wrong / what should be happening instead: Unless I missed something, I would think that this would allow you to cd into the directory and browse the files just as if they were on the C: drive.

Does anyone have any pointers or a valid solution?
Thanks.

[sunilmut]

cd into a Windows Symlink works when it is not a mapped network drive i.e a regular directory. Concur that it doesn't work when the symlink points to a mapped network drive. Currently, mapped network drives are not auto-mounted in bash. As a workaround, you can explicitly mount network drives in bash using `mount -t drvfs /mnt/"

Adding @SvenGroot

[BlackHoleFox]

@sunilmut Would you be able to clarify the use of the command that you said to use? Mount is still not showing any drives but my two internal disks for mounting.

[SvenGroot]

There are two problems here. The first is that, as @sunilmut indicated, network drives are not automatically mounted in WSL. You can mount them manually with the following commands:
sudo mkdir /mnt/z
sudo mount -t drvfs Z: /mnt/z

You can also use the UNC path directly instead of the mapped drive letter.

However, the additional problem is that WSL cannot currently resolve absolute links to a network drive, even if it is mounted. When WSL sees an absolute NT symlinks, we try to see if we have a matching DrvFs mount for the link's target by using the drive's volume GUID. Network drives do not have a volume GUID, so this approach doesn't work. Improving our support here is on the backlog.

[HuJK]

Is there an config file like /etc/fstab so that we can specify the path manually?

It's better than we can't access it at all.

[STaRDoGG]

Almost 3 years later and I'm still fighting with this (and losing, painfully).

All I want to do is mount a music folder containing my music library to my windows network, then mount that in a Docker container (Airsonic).

So far, impossible.

If I simply mount the shared folder within WSL (ubuntu) using drvfs/cifs, and then bind mount that mount to my container, I can see all the shared files from within WSL/ubuntu itself using ls, but viewing the contents of the directory from within the container shows an empty dir.

i.e.

sudo mount -t cifs -o username=yourname,domain=yourworkgroup //192.168.0.195/Music /media/shared/music

(I've also tried with drvfs, as well as adding vers=1.0)

Oddly, if the container creates a file that gets saved to that mounted dir, I can see the new file in windows, but nothing changed in the WSL dir.

If I create a symlink in Windows:

mklink /d "F:\Airsonic\Music" "\\192.168.0.195\Music"

and then mount it in a container:

- /mnt/f/Airsonic/Music:/music

I can see the shared files fine within windows, but trying to view them within WSL just gives me:

ls: cannot read symbolic link 'Music': Input/output error

This is WAY too much of a hassle than it should be, and I still haven't found a way to get it working.

[obsgolem]

I believe I have just run into a similar version of the same issue when using imdisk's mount point feature. When I use this feature I end up with a mounted folder whose target is \Device\ImDiskN\. This folder is then impossible to interact with in WSL with the same error as op.

[YouveGotMeowxy]

Improving our support here is on the backlog.

@SvenGroot Can you put it on the frontlog? It's been 4 years now. ;)

I have a TB external drive that I store my music and my eBooks on that I share with t he whole network; I want to use eBook library and music library containers now for them, but ....

Seems like a fairly common case scenario.

[koyae]

Bump. I'm also affected by this bug. It's a real bummer.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!