Support for vaults in Windows Subsystem for Linux (WSL)

Feature requests
1

I’m wondering if there will be support added for using vaults inside of WSL?

Currently when I open a vault inside WSL, it errors out and never loads. The main driving factor for wanting the vault inside WSL for me is so that I can keep it under version control and I prefer to keep my developer tools (like git) in a Linux environment, as opposed to using something like git-scm

Steps to reproduce

  1. Open obsidian on Windows
  2. Create a new vault, place it in a WSL path (e.g. ‘\\wsl$\Ubuntu\home\user\test’

image

Expected result

Obsidian operates as normal

Actual result

Obsidian errors and never loads:

image
image1833×685 35.8 KB

Error text for convenience:

Uncaught (in promise) Error: EISDIR: illegal operation on a directory, watch '\\wsl$\Ubuntu\home\aidan\test\'
    at FSWatcher.start (internal/fs/watchers.js:165)
    at Object.watch (original-fs.js:1329)
    at e.startWatchPath (app.js:1)
    at e.<anonymous> (app.js:1)
    at app.js:1
    at Object.next (app.js:1)
    at app.js:1
    at new Promise (<anonymous>)
    at s (app.js:1)
    at e.watch (app.js:1)

According to stackoverflow, EISDIR means it’s trying to do a file operation on the test directory.

According to a similar issue, it could be related to cmd.exe not handling UNC paths.

Interestingly, it does create some of the files, so some of the filesystem operations appear to work:

~ find test
test
test/.obsidian
test/.obsidian/config

Environment

  • Operating system: Windows
  • Obsidian version: 0.9.11

Additional information

Additionally, if WSL support is planned, I’d like to see support for using the WSL environment/path variable similar to how VS Code works, so that way plugins like obsidian-git will work with the git from WSL as opposed to having to install git for windows.

If WSL support is too hard for now I completely understand.

14 Likes
2

I am gonna move this to feature requests.

4 Likes
3

Thanks! Sorry I wasn’t sure whether this was supposed to be working and thus a bug or whether it hadn’t been implemented yet.

4

It seems to be a bug. I have the same problem with a folder on a Cryptomator drive.

5

Just ran into this as a new obsidian user. Big +1 on this request. WSL/WSL2 are excellent.

1 Like
6

Also ran into this issue. Another +1 on this as a feature/bug fix request.

1 Like
7

I can confirm that some of the file operations are working, specifically the creation of the .obsidian folder and the related config file:

image

For context, this is the complete contents contained within the config file before the aforementioned crash:

image

To my knowledge, EISDIR stands for Error, Is Directory which would lead me to believe that Obisidian is trying to read a file when in fact that file is a directory, not a file.

To add some more context, it seems to be an issue specifically with the watcher. Unfortunately, I can’t say I am savvy enough with how everything works to pinpoint the exact problem, but I do think it is an issue with UNC paths. The error results from within the start FSWatcher function:

image
image1715×1034 119 KB

Note that in the above function, the filename is wrapped in the function toNamesSpacedPath(filename). Below is the function itself:

image
image745×678 23.2 KB

For those with a better understanding than myself, it may be worth a dive into either the watcher start function or this toNamesSpacedPath(filename) to pinpoint a solution.

3 Likes
8

Great sleuthing up there!

This is important for anyone git cloning their entire repos (to include .obsidian, etc) between different platforms. I get a ton of filepath/name issues going from osx to Windows which kills the app, so I use my wsl mount to get around that but unfortunately the app dies with the ErrDir there. Thought I had a trick up my sleeve lol

Won’t be a huge deal for me once sync can sync everything but it’ll confuse some users I’m sure. Glad someone else ran into this and mentioned it.

9

Any comments from the devs about WSL support, please? Thanks! :blush:

Edit: By the way, while it does not work, could Obsidian show a descriptive error message like: Sorry, WSL is not supported at the moment when a user tries to open a vault located in WSL?

1 Like
10

+1 on this feature request. Joining to get updates.
I am so excited I found Obsidian but all my repo are in WSL so I cannot use it unfortunately.

FpuU1wZJ1u
FpuU1wZJ1u1274×997 27.9 KB

2 Likes
11

Having delt with WSL in many esoteric cases, It’s highly likely that something closely related to the filesystem between windows and linux and therefore not something that can easily be fixed by the dev team. It may cause unpredictable behavior.

On a related note, you should be able to use access the host filesystem from the WSL instance. Nothing is preventing you from using the host computer and simply navigating bash to the vault directory to use git.

12

With WSL2, it’s recommended to have the code in the WSL filesystem for best performance, that’s why I have them there.
I never had issues opening files from WSL with any other tools on Windows, though, so not sure why it crashes with Obsidian.

2 Likes
13

Has anyone tried to use Windows 11 + WSL2 + Obsidian installed in WSL (not only a vault stored in WSL)? At least in Windows 11 it should be possible to run graphical applications in WSL.

1 Like
14

Has anyone tried to use Windows 11 + WSL2 + Obsidian installed in WSL (not only a vault stored in WSL)? At least in Windows 11 it should be possible to run graphical applications in WSL.

This is most likely to work without issues.

With WSL2, it’s recommended to have the code in the WSL filesystem for best performance, that’s why I have them there.

You’re right for the tools like git and other things, but given that you are mostly working with text files, I don’t think it’s really that big a performance hit to put them on the windows side. I’ve hosted git repos on the windows side and worked with them in WSL and had no issues.

More detail:

WSL2 is based on a VM, which means that the filesystem working on WSL environment is native linux ext4. So when working with linux tools it will be much faster. However, the permissions model is not really the same between windows and linux.

Moreover if you look at the specific bug you cited by the OP, the issue has to do with file watchers. In linux this is implemented as as part of the kernel. basically when a something fetches the inode, the kernel will notify the watchers that there is something that changed.

NTFS (native windows system ) doesn’t have the filesystem watcher mechanisms implemented in the same way. It would be a horrible hack at best to get this working on the Obsidian side. The only alternative is to expect the WSL team to translate filewatchers to operate in the same way as linux. (they might do it sometime but it’s likely way low on their priority list.)

Bottom line, this is one of those edge cases where there is a lot going on under the hood. You might be better off just installing the Linux version of obsidian in WSL.

15

Works but brings other issues like the “paste” of images or other files that were “copy” to the clipboard of Windows …

To use the snap version on WSL2 is more tricky, but the .AppImage version is straightforward … just download and execute it (./Obsidian-0.12.19.AppImage) inside your WSL2 shell and the GUI will appear on Windows.

As it has the issue with the clipboard I still prefer to use the Windows native version pointing to my vault in WSL2 (as I have case sensitive files) … but I have a EACCES error with a soft link I have in my repo, so +1 here for a better WSL support :+1:

2 Likes
16

I think your probably running into some esoteric issue with X11 and clipboard sharing, but I’m just guessing. I’d need a much more clearer picture of how you are running obsidian to understand what and how to debug.

Options:

  • Obsidian running in Windows with Windows filesystem (should be no issues here accessing from WSL)
  • Obsidian running in windows with WSL2 filesystem (slow with weird permissions/filesystem issues)
  • Obsidian running in Linux with WSL2 filesystem (slow with really weird permission/filesystem issues)
  • Obsidian running in linux with windows filesystem (probably issues with X11 and anything graphical)

If all you want to do is access your vault files from WSL, then the first option is the best. You will avoid all the weirdness with filesystems and UI in this setup and everything should work natively.

Otherwise you are asking the devs to manage the kernel level filesystem issues from a userland program. It’s not a reasonable ask.

1 Like
17

We strongly recommend you to search the forum with possible keywords before making a new feature request. If your request is very similar to an existing one, consider liking it and/or making a comment rather than making a new one. Once you’ve searched and determined that this is a new request, delete this line.

Use case or problem

Opening a vault from wsl2 directory is not supported. It gives an error

An error occurred while loading Obsidian. Error: EISDIR: illegal operation on a directory, watch '\wsl$\Ubuntu-20.04\path\to\docs

Proposed solution

wsl2 filesystem is integrated into Windows filesystem (I have Windows 10) very well and works with most of windows apps (explorer, browser and other windows apps)

It would be easy to create and manage markdown files using vim editor. Most importantly the docs can be maintained in place rather than moving it to Windows filesystem. Managing files will be easier and intuitive.

It would be great, if this feature is made available.

Current workaround (optional)

There is no workaround.

Related feature requests (optional)

18

I am on the Win11 latest dev build and it works fine with either \\wsl.localhost\wslname\home\me or \\wsl$\wslname\home\me

1 Like
19

FWIW, your home directory within WSL is actually within the Windows filesystem. (I’m on Win 10)

Mine resides at (brace yourself):
C:\Users\kauffy\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\rootfs\home\kauffy

If memory serves, that _79rhkp1fndgsc is not unique to me, but is part of the package name, so it’s like the same on your system.

1 Like
20

Are you running WSL and not WSL2 ? because I don’t see that in my wsl2 version beyond home. The ‘home’ directory is empty

Good to know that pshev is able to use \wsl$\ file system, but I am not sure whether I can go to Win11 any sooner …

Thanks for the inputs