Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't access network drives (shared folders) #58

Closed
TheDcoder opened this issue Oct 16, 2021 · 6 comments · Fixed by #73 or msys2/MSYS2-packages#2771
Closed

Can't access network drives (shared folders) #58

TheDcoder opened this issue Oct 16, 2021 · 6 comments · Fixed by #73 or msys2/MSYS2-packages#2771

Comments

@TheDcoder
Copy link

@TheDcoder TheDcoder commented Oct 16, 2021

Hi, I apologize if this is the wrong place to post this issue.

I recently installed MSYS2 on my Windows 10 VM in VirtualBox, and I quickly found out that I can't navigate to any of my shared folders (which are mounted as Network Drives in Windows). The primary error message is Too many levels of symbolic links.

Here is some raw output from the shell:

$ cd /t
bash: cd: /t: Too many levels of symbolic links

$ df
df: /b: Too many levels of symbolic links
df: /g: Too many levels of symbolic links
df: /j: Too many levels of symbolic links
df: /p: Too many levels of symbolic links
df: /t: Too many levels of symbolic links
Filesystem        1K-blocks     Used Available Use% Mounted on
C:/Software/msys2  51849068 29908016  21941052  58% /
D:                    59642    59642         0 100% /d

Drive D is a CD-drive and I am able to access it normally, as well as the C drive (/c). All of my projects are on the host system so I need to access them via mechanisms such as shared folders, which are implemented as network drive mounts in VirtualBox's Windows guests.

I am able to use cmd and powershell normally in network drives as well as many other programs, this is one of the rare occasions where they have caused me trouble, I don't even recall the last issue I had with them.

@jeremyd2019
Copy link
Member

@jeremyd2019 jeremyd2019 commented Oct 16, 2021

#46 ? Try setting MSYS=nonativeinnerlinks before starting the shell. I don't know if that would work here though, as those are not really inner links at that point. Try cd to a subdirectory of one of those mounts too in that case.

@jeremyd2019
Copy link
Member

@jeremyd2019 jeremyd2019 commented Oct 16, 2021

Also maybe take this to upstream cygwin. This update to symlink code has caused issues here, but I don't think cygwin has released a version including those changes yet, so we're getting all the reports of the fallout.

@TheDcoder
Copy link
Author

@TheDcoder TheDcoder commented Oct 16, 2021

@jeremyd2019 Thanks for the super-fast response! 🚀

The nonativeinnerlinks option seems to have fixed the issue 😁

C:\Software\msys2>set MSYS=nonativeinnerlinks

C:\Software\msys2>msys2_shell.cmd

C:\Software\msys2>mkdir T:\Test
John@DESKTOP-IK5KE4H MSYS ~
$ cd /t

John@DESKTOP-IK5KE4H MSYS /t
$ cd Test

John@DESKTOP-IK5KE4H MSYS /t/Test
$ ls

Also maybe take this to upstream cygwin.

I am reluctant to do so because I don't really use cygwin.

This update to symlink code has caused issues here, but I don't think cygwin has released a version including those changes yet, so we're getting all the reports of the fallout.

I see. Pardon my ignorance but does this new symlink code improve performance or is it more of an architectural change?

@jeremyd2019
Copy link
Member

@jeremyd2019 jeremyd2019 commented Oct 16, 2021

My understanding is that it fixed an issue in cmake's tests, but it also causes issues with mapped and subst drives, and possibly docker mount points? @github-cygwin

@LordAro
Copy link

@LordAro LordAro commented Oct 22, 2021

This also causes issues with mapped volumes with docker containers with the same "too many levels of symbolic links" error.

docker run --rm -it -v C:\localdir:Z: my-msys C:\msys64\usr\bin\bash.exe -lc "ls /z/"
ls: cannot access '/z/': Too many levels of symbolic links

Setting MSYS=nonativeinnerlinks fixes the issue

@jeremyd2019
Copy link
Member

@jeremyd2019 jeremyd2019 commented Dec 8, 2021

30089b3 is supposed to have fixed this. It would be interesting to see if it fixed the Docker issue too (it seems likely it did)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants