Fix brokenness right after install

[rennex]

I installed wsltty after I had already configured my Ubuntu a little bit, and wsltty didn't work out of the box at all. It just flashed a window and quit immediately.

• I'd like to propose that by default, wsltty should keep the window open on error.

The actual error in my case was that there was no permission to execute wslbridge-backend on Ubuntu. And this was because I had configured the mount options as metadata,umask=022,fmask=0111 - that is, regular Windows files don't appear as having the execute bit set. But the metadata option let me set it myself:

chmod +x /mnt/c/Users/username/AppData/Local/wsltty/bin/wslbridge-backend

After this, wsltty started working fine. Maybe wsltty should even automatically try doing this chmod before trying to run that binary?

[Biswa96]

In my PC , it works well without that mount options. By default all files in wsltty/bin folder are with 0777 permission. Did you add any extra configuration in WSL?

[rennex]

Yes, I added those mount options myself, because it's crazy to have all files appear executable by default. That interferes with git, for example. So now, files from the Windows side appear with 0644 permissions, unless I separately set +x on them. This works great for almost everything, except in cases like this where a program lives on both OSes at the same time.

[mintty]

Is it possible to get the WSL +x attribute set by some manipulation on the Windows side? Maybe with some Windows tool, or cygwin chmod? Then it could be fixed during installation. Otherwise it will be up to wslbridge to fix the scenario.

[rennex]

Yes, in Windows if I open cmd.exe and cd into that wsltty\bin directory, I can run:

wsl chmod +x wslbridge-backend

And that does the trick.

I'm not sure if wsltty already does something to figure out where the Windows folder is actually mounted (if the user has changed it from the default), but if not, wsl realpath wslbridge-backend would return the Ubuntu-side path.

[mintty]

OK, let's consider this scenario (I could try myself, but not so soon): You have 2 WSL installations, Ubuntu with those mount options, and, say, openSUSE without specific mount options. Let's say openSUSE is your default installation, so wsl will run it. Would the above command also set the +x attribute as seen in Ubuntu?

[rennex]

I'm not sure how exactly the extra metadata is stored; it may be somehow tagged per-distro, or just one common set for all distros. All I know is that the metadata stays in the file, even if you move it on the Windows side.

If it's per-distro, wsl.exe has the -d option to specify a distro by name. I guess the wsltty installer already lists existing distros, since the start menu shortcut that it made got a --WSL="Ubuntu" parameter on my system. So the chmod could be done for each distro if needed?

[Biswa96]

Understood your issue. I do use those mount options in my real Linux system. But in WSL, we should not** manipulate any file permission from Windows side by any means. See this blog post. In newer Windows 10 version, WSL has added 9P server but that also has some caveats and headaches.

_{^{** But that does not mean we could not}}

[mintty]

That warning is not applicable, for 2 reasons: The file is not in the distro's filesystem (I think it was different in the wsltty appx setup...) and with the proposal to use wsl chmod it is not manipulated with a Windows tool. So I see no problem here.

[mintty]

I haven't yet had time to test the scenario requested above; can somebody confirm it works? Reminder: 2 distros S and U, S "normal" (no specific mount options), U with mount options that prevent +x by default. Set +x using distro S. Will +x appear to be set in distro U?

[Biswa96]

Will +x appear to be set in distro U?

No, it does not appear as you said.

S "normal" (no specific mount options)

If no mount options specified all files appears with 0777. But my mind becomes confused after seeing this blog post.

[mintty]

Thanks for the link. It says:

If you have multiple WSL distros installed or multiple Windows users with WSL installed, they will all use the same metadata on the same files.

Maybe that does not include distros without metadata enabled? Maybe we should report that as a bug to MS?

[Biswa96]

That already listed it in 'important caveats'. So I would not suggest to make a issue there. WSL implementations of Linux file attributes also depend on Windows 10 versions. From Windows 10 insider build 18860, drvfs metadata is default. So use cases may vary.

I would suggest to add some lines in wsltty README. For example, "if you see... this issue... try this simple command... to fix". Also I'd love to hear other opinions @rennex.

[mintty]

Cannot reproduce the issue. All distros have C: already mounted, without metadata, and refuse to unmount it... Honestly, I'm kind of fed up with this crap. If they want to give us Linux, they shouldn't again invent all their own stuff. Anyway, as another idea, the installer could try a brute-force approach and just wsl chmod with all available distributions...

[mintty]

What about .exe files? Are they lacking the +x attribute as well?

[Biswa96]

As I said my use cases will vary because I'm using Windows insider builds OP may help :)

[felipe1982]

I just installed 3.0.0 and I get flashing screen issue too. WSLTTY won't start up successfully. Doing ls inside my ./bin folder shows:

felipe@DESKTOP-TCPCKB9:/c/Users/Felipe Alvarez/AppData/Local/wsltty/bin$ ls -la
ls: cannot access 'wslbridge-backend': No such file or directory
ls: cannot access 'wslbridge-backend.old': No such file or directory
total 9.0M
drwxr-xr-x 1 felipe users  512 Apr 30 13:12 ./
drwxr-xr-x 1 felipe users  512 Apr 30 13:12 ../
-rwxr--r-- 1 felipe users 3.4M Apr 11 15:02 cygwin1.dll*
-rwxr--r-- 1 felipe users 3.2M Oct  5  2018 cygwin1.dll.old*
-rwxr--r-- 1 felipe users  19K Apr 11 15:02 cygwin-console-helper.exe*
-rwxr--r-- 1 felipe users  99K Apr 11 15:02 dash.exe*
-rwxr--r-- 1 felipe users 643K Apr 11 15:02 mintty.exe*
-rwxr--r-- 1 felipe users  25K Apr 11 15:02 regtool.exe*
-????????? ? ?      ?        ?            ? wslbridge-backend
-????????? ? ?      ?        ?            ? wslbridge-backend.old
-rwxr--r-- 1 felipe users 809K Apr 11 15:02 wslbridge.exe*
-rwxr--r-- 1 felipe users 809K Oct  5  2018 wslbridge.exe.old*
-rwxr--r-- 1 felipe users  88K Apr 11 15:02 zoo.exe*

I tried chmod +x, but it complains file is not found.

I tried in cmd using wsl chmod +x wslbridge-backend but I also get file not found.

I am stuck using default WSL terminal. Please help.

C:\Users\Felipe Alvarez\AppData\Local\wsltty\bin>dir
 Volume in drive C is OS
 Volume Serial Number is 8CF8-8920

 Directory of C:\Users\Felipe Alvarez\AppData\Local\wsltty\bin

30/04/2019  01:12 PM    <DIR>          .
30/04/2019  01:12 PM    <DIR>          ..
11/04/2019  03:02 PM            18,451 cygwin-console-helper.exe
11/04/2019  03:02 PM         3,492,318 cygwin1.dll
05/10/2018  06:54 PM         3,335,398 cygwin1.dll.old
11/04/2019  03:02 PM           100,883 dash.exe
11/04/2019  03:02 PM           658,432 mintty.exe
11/04/2019  03:02 PM            25,107 regtool.exe
11/04/2019  03:02 PM           150,568 wslbridge-backend
05/10/2018  06:54 PM           150,568 wslbridge-backend.old
11/04/2019  03:02 PM           828,416 wslbridge.exe
05/10/2018  06:54 PM           828,416 wslbridge.exe.old
11/04/2019  03:02 PM            89,600 zoo.exe
              11 File(s)      9,678,157 bytes
               2 Dir(s)  322,699,476,992 bytes free

/etc/wsl.conf:

C:\Users\Felipe Alvarez\AppData\Local\wsltty\bin>wsl cat /etc/wsl.conf

[automount]
enabled = true
mountFsTab = false
root = /
options = "metadata,umask=22,fmask=11"
[network]
generateHosts = true
generateResolvConf = true

[Biswa96]

See the first post in this thread. Use full path of wslbridge-backend in that command.

[felipe1982]

That also is unsuccessful

felipe@DESKTOP-TCPCKB9:~$  ls -l '/c/Users/Felipe Alvarez/AppData/Local/wsltty/bin/'
ls: cannot access '/c/Users/Felipe Alvarez/AppData/Local/wsltty/bin/wslbridge-backend': No such file or directory
ls: cannot access '/c/Users/Felipe Alvarez/AppData/Local/wsltty/bin/wslbridge-backend.old': No such file or directory
total 9.0M
-rwxr--r-- 1 felipe users 3.4M Apr 11 15:02 cygwin1.dll*
-rwxr--r-- 1 felipe users 3.2M Oct  5  2018 cygwin1.dll.old*
-rwxr--r-- 1 felipe users  19K Apr 11 15:02 cygwin-console-helper.exe*
-rwxr--r-- 1 felipe users  99K Apr 11 15:02 dash.exe*
-rwxr--r-- 1 felipe users 643K Apr 11 15:02 mintty.exe*
-rwxr--r-- 1 felipe users  25K Apr 11 15:02 regtool.exe*
-????????? ? ?      ?        ?            ? wslbridge-backend
-????????? ? ?      ?        ?            ? wslbridge-backend.old
-rwxr--r-- 1 felipe users 809K Apr 11 15:02 wslbridge.exe*
-rwxr--r-- 1 felipe users 809K Oct  5  2018 wslbridge.exe.old*
-rwxr--r-- 1 felipe users  88K Apr 11 15:02 zoo.exe*
felipe@DESKTOP-TCPCKB9:~$ chmod +x /c/Users/Felipe\ Alvarez/AppData/Local/wsltty/bin/wslbridge-backend
chmod: cannot access '/c/Users/Felipe Alvarez/AppData/Local/wsltty/bin/wslbridge-backend': No such file or directory
felipe@DESKTOP-TCPCKB9:~$

[mintty]

What's your distribution? I observe the same with Alpine Linux but it works with the dedicated binary of wslbridge-backend, see #156.

[felipe1982]

My distro is OpenSUSE Leap 15. I do not think I know how to generate that binary.

[Biswa96]

I've tried your settings with Arch, Debian, OpenSUSE. No issue in my system Windows 10 18860. Can you try with this:

[automount]
options = "metadata,fmask=133,dmask=022,uid=1000,gid=1000,case=off"

[mintty]

the installer could try a brute-force approach and just wsl chmod with all available distributions...

Or maybe the wslbridge frontend could do that if the backend invocation fails; can it detect this case of failure, however?

[felipe1982]

Wanted to report that restarting the computer after some windows updates solved the problem 🤷‍♂️ 😪

[rennex]

Regarding the original discussion, I think it makes sense that distros which mount C: without metadata, will ignore any metadata that other distros may have set. They'll also see all files as having the execute flag by default, and they will work without any chmodding. But when metadata is enabled and files appear without +x by default, the chmod trick fixes them, and that commit from a few days ago looks like it'll fix the situation. 👍

[mintty]

Released 3.0.1.