@rohanray Tried it with mantra-sample-blog-app - FAILED 
Nope. It’s actually meteor-tools themselves which bomb out, leaving you with a non-working meteor installation.
Update: Everything seems to be working now!
I’ve only heard about Windows 10’s bash today. Installed the bash application, installed meteor, installed node, installed npm. Minor errors in the process. Now running meteor on windows with all the code refresh speed of linux. This should be better publicized somewhere in the Meteor community as it’s one of the biggest criticisms among Windows users.
My process:
- Installed Windows Bash by following: http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/
- Installed meteor via “curl https://install.meteor.com/ | sh”
- Tried running “meteor” command on existing project. Bash returned a promises related error and exited. Tried running “meteor reset” and received message that it could not be executed because meteor was already running, even though there was no server at localhost:3000. Tried running meteor again. Did not receive promises error, but received an npm related error.
- Installed node and npm via “sudo apt-get update”, “sudo apt-get install nodejs”, “sudo apt-get install npm”
- Ran “meteor” - everything working smoothly
1 Like
I get:
seba@KORCLT29912:~$ curl https://install.meteor.com/ | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7592 0 7592 0 0 18983 0 --:--:-- --:--:-- --:--:-- 19027
Downloading Meteor distribution
curl: (22) The requested URL returned error: 403 Forbidden
Retrying download in 5 seconds...
Edit: so this is probably a general issue and not related to bash on windows.
The tarball it tries to download is:
https://meteorinstall-4168.kxcdn.com/packages-bootstrap/1.4.1.1/meteor-bootstrap-os.linux.x86_64.tar.gz
which indeed gives a 403 error. Created an issue: https://github.com/meteor/meteor/issues/7697
1 Like
Okay, so after manually changing the install script for now, I got meteor installed and running on bash for windows.
Sadly, it is pretty useless.
What works is creating and running a meteor project on the linux file system (e.g. your linux home directory). But that’s pretty useless, since you can’t open it in any GUI. So this is only for the vim people among us.
Running a meteor project on the windows file system from the ubuntu bash (e.g. under /mnt/c/...) does not work, since mongo can not start. You get:
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Can't start Mongo server.
MongoDB had an unspecified uncaught exception.
This can be caused by MongoDB being unable to write to a local database.
Check that you have permissions to write to .meteor/local. MongoDB does
not support filesystems like NFS that do not allow file locking.
Too bad, I really hoped this could work.
I might try to see if I can install X server and open GUI applications that way, like you would do with a remote terminal session.
1 Like
Heh, seba, it seems this issue is suffering from a doubled thread discussion (anyway to “merge” discussions in discourse?).
You are probably having the same issue I described here Just an FYI: Bash on Windows 10 now available .
So, it looks like if a Meteor project has the MongoDB originally built on Windows it runs properly. However, if you build/reset the project with bash, Mongo becomes unable to start. According to the warning messages I mentioned in my post, this might be related to the MongoDB engine being used. Mongo engines are beyond my scope of knowledge, but I’ll leave the hanging thread here if anyone wants to follow it.
In the meanwhile, bash is quite useful in my specific use case - faster code refresh and bash command sweetness on a previously existing project built on Windows.
Oh okay. I’ll leave it up to the moderators to merge the threads and continue here for the time being.
Problem is that I’m mainly experiencing very slow rebuild times because of AV-software which is corporate regulated (I can’t turn it off). I hoped using the linux file system would do away with this problem. But it seems I still need to use the windows file system.
With 20 years in dev I know the feeling and it will not change apart from that down the road it will be entire languages and platforms you’ve put years into, that will be made redundant and you have learn new stuff. But I wouldn’t have it any other way. It’s progress and that’s good. Old timer out.
Using this guide: http://windowsclan.com/developers-running-linux-gui-apps-windows-10-using-bash/
I’ve been able to run firefox from windows on bash (although without hardware acceleration and so on)
However, I can’t seem to run any of the GUI’s I’ve tried: webstorm, atom and vscode.
Many existing Meteor projects from Windows seem to run fine on Ubuntu Bash after cloning them into the linux file system, e.g. /home/… So, to still use our favorite editor on Windows, every time we hit save, we could sync the changed project file from Windows filesystem to a folder on the linux filesystem, couldn’t we?
Tried it manually at least with rsync (and tmux) and it works as expected: meteor recognizes the changes as usual and processes them. Next step is to automate the syncing or let rsync check for changes in a short intervall.
Did anybody tried this stuff, too? What do you think?
I’m not sure I understood you correctly, but if I did I think you are seriously over complicating it. You do not need to clone meteor into the linux file system, as Bash is able to access the windows file system (at /mnt/c). My use case is exactly what you said - favourite editor on Windows and running meteor on Ubuntu Bash, meteor detects code changes, Chrome on Windows reloads.
How I achieve it:
- Open Atom on Windows
- Open Bash
- run cd …/…/mnt/c/Users/(my meteor dir)
- run meteor
- Profit
2 Likes
I’m really not sure how you guys are running your Meteor projects directly under the /mnt/c directory.
Because that particular mount is a linked NTFS filesystem which really doesn’t like file-locks / symlinks (at least the way *nix does it). Every time I tried to use that directory, Meteor would crash and burn.
Just for the sake of updated information:
It doesn’t seem to work after the last updates. I am receiving the same error as presented at http://stackoverflow.com/questions/38818714/meteor-npm-install-produces-error-eio-i-o-error
@sashko After trying to use bash on windows with meteor for a while, I can tell you it isn’t ready for day to day development. Still a lot of weird issues with mounting the files, symlinks, git, and even using an editor that’s installed outside of bash.
For now, I really appreciate all the work you put into the windows version
2 Likes
Please make Meteor works with bash 
Even if the meteor tool were to work perfectly inside bash for Windows, where should the project be located and how should the editor access it?
That is, should we keep the project inside the emulated Linux filesystem, or in the regular Windows filesystem under /mnt/c? I’d be incredibly surprised if the Linux file-watching API somehow worked and detected file updates on Windows through the emulation layer. Has anyone tried this?
I’ve tried it both ways and I can’t get either to work. The permissions always end up broken, the file watching for auto reload falls apart, and the two operating systems fight with each other trying to reformat tabs and spaces constantly which destroys you commits on git. You even get bizarre errors where each OS will see different versions of the file depending upon which edited it last.
I tried for about a day to get it to work, but I never got it to a point where it was stable enough for me. It just isn’t ready for professional development yet. I have no doubt that if they keep working on it will be really useful in the future if they can iron out the current issues. Bash on Windows has amazing potential!
Oh, it does work. You just have not to be afraid of symlinks.
The easiest way to go at it is using Git (or some other kind of repository).
You first clone your repo into a folder in Windows (like C:\Users\username\documents) and then do the same inside Bash (Do a cd ~ first, though, because otherwise you won’t be in your home folder).
Then you symlink almost everything from Bash to the Windows repo like thus:
git clone reponame
cd ./reponame
rm -rf ./public
ln -s /mnt/c/Users/username/documents/reponame/public
rm -rf ./client
ln -s /mnt/c/Users/username/documents/reponame/client
rm ./package.json
ln -s /mnt/c/Users/username/documents/reponame/package.json
rm ./.meteor/versions
ln -s /mnt/c/Users/username/documents/reponame/.meteor/versions
....
VERY IMPORTANT: The ln -s must NOT have a trailing slash. There’s a bug with the UbuntuOnWindows implementation which creates an infinite recursion if you create a symlink to a directory if the target directory’s path has a trailing slash.
Basically, you symlink everything except the /.meteor/local and /node_modules/ folders.
If you did everything right it should then look like this:
2 Likes
@rhywden oh nice, glad you figure it out! I was not using symlinks the way you were so that probably what I was missing. I’ll give it a second change when I have a minute.
It’s good that you got that to work, but it’s kind of insane to have to do that for every meteor app I want to develop.
How does the file watching work in that case anyway? The Linux file-watching API goes through the symlinks and somehow manages to function properly in the Windows filesystem?