Is there a reliable way to avoid permission denied errors when installing Ruby gems with native extensions on Windows Subsystem for Linux?

Question

I'm hoping that WSL2 solves these problems and makes this question obsolete in the next 6 months or so, but in the meantime, I don't feel comfortable running bleeding edge or other preview releases of Windows on my primary laptop.

Sometimes, when I'm installing Ruby gems (bundle install or bundle install --path=vendor/bundle) inside of WSL, I get Permission denied errors when installing a gem with a native extension.

The most recent incarnation of this error was this:

Permission denied @ rb_file_s_rename - (./.gem.20191006-12131-11th7ub/byebug, /home/thomasowens/project/vendor/bundle/ruby/2.6.0/extensions/x86_64-linux/2.6.0-static/byebug-11.0.1/byebug)

To resolve it, I simply deleted /home/thomasowens/project/vendor/bundle/ruby/2.6.0/extensions/x86_64-linux/2.6.0-static/byebug-11.0.1/byebug, reran the bundle command, and it succeeded. Sometimes, I need to do this multiple times, but it usually works.

In the end, I can get all of the gems installed properly, but it's hard when setting up a new project and there are many gems with native extensions. Same when I'm introducing a new gem or updating a gem that causes the native dependencies to need to be updated.

I haven't found much about this issue, but I'm wondering if there is something that I can do to alleviate the pain of needing to run bundle install multiple times to get a project set up and running under WSL.

Answer 1

The problem that I'm experiencing may be related to Visual Studio Code's file watching. It is reflected in two GitHub issues against WSL - 1956 and 3395. Visual Studio Code has remote.WSL.fileWatcher.polling, which can be enabled which works around this issue. However, the documentation states that there is a performance impact for large workspaces and it may be necessary to also adjust the remote.WSL.fileWatcher.pollingInterval setting. WSL2 will resolve these issues.

Since enabling this flag, I haven't seen the error while working with VS Code running.

---

Now that WSL2 is out, I was able to disable this flag and the issue has not reappeared. It appears that if you can upgrade to WSL2, that may be a preferred solution. However, for anyone who hasn't yet upgraded or can't upgrade, toggling the remote.WSL.fileWatcher.polling and remote.WSL.fileWatcher.pollingInterval should be good.