Insecure world writable dir /mnt/c in PATH

[Valtasaar]

Hi!
When I install gems I see this warning.
Is it possible to fix this?

Windows build: 15063.483
Version: 1703

[therealkenc]

Remove /mnt/c from your path. #2461 (message).

One somewhat modest proposal on the slow boat to /etc/fstab would be for drvfs to support:

sudo mount -t drvfs -o umask=0755,uid=1000,gid=1000 C: /media/ken/c 

That feature would be nice to see, in isolation, without otherwise changing the current behaviour.

[Valtasaar]

Remove /mnt/c from your path. #2461 (message).

I don't have this registry key. Can I create it?

[ghost]

I love ruby, but ruby is here excessively verbose where it really does not need to be.

What is even worse, to the best of my knowledge there is no trivial way to tell ruby to just shut up here. I, and various others, have suggested better fine-tuned control for ruby's warning system to ruby-core but this will probably take until ruby 3.x is released (ruby-core is very busy too, unfortunately... so things get queued up... plus ruby kaigi is coming in japan soon, so they are preparing for that event).

There are some ad-hoc workarounds. Modifying the $VERBOSE variable can probably help. You can keep a reference copy to the old value, set $VERBOSE to nil, and then restore the old value again. I use this in some of my older gems... but it's a bit annoying still to do.

Another way would be to run gem install via a "sandbox" where you invoke IO.popen; that way you can control what is output to you as a user, if the above really disturbs you. It disturbs me too, by the way, but it can also be ignored - it's just a warning. A pointless one but still only a warning.

For example, the variant via IO.popen would be like this:

cmd_to_run = 'gem install foobar-1.0.0.gem'
io_object = IO.popen(cmd_to_run, :err => [:child, :out]).each { |line|
  # do stuff here; if you want to output the line, do puts line
}
io_object.close

Put this into a method, where the input argument should be the name of the .gem file - et voila. (Don't forget to put stuff into the {} lines... like just for debugging purpose; and perhaps also show the command that is to be run, just so you know that things happen, rather than everything be silent.)

It's a bit verbose but that way you get 100% control over the message that is output; you can also play with 2>&1 and select streams that you want to have. See also ruby Kernel's select().

But to be honest, the proper way to fix it would be upstream at ruby; either to disable this message, which hasn't been in older ruby versions (good approach) or allow people to fine tune and control warnings as they want to (the more sophisticated approach).

Of course there are also other ways such as named by therealkenc - but the thing is... I think that the one at fault here is ruby, not the underlying OS or file system. Perhaps changing the permissions works as therealkenc showed, I haven't yet tried myself but it would make sense if this can be done.

I don't have this registry key. Can I create it?

Hmm. Are you sure that not $PATH was meant from within the bash-shell, rather than the windows registry?

[therealkenc]

I don't have this registry key. Can I create it?
Hmm. Are you sure that not $PATH was meant from within the bash-shell, rather than the windows registry?

You can set an absolute $PATH in your .bashrc. Or opt out entirely with the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss]
"AppendNtPath"=dword:00000000

If the entry doesn't exist, create it. [I have never set the flag personally, YRMV.] Your fix is even better. With the registry change you'll lose WSL interop via $PATH. Still hope we get the drvfs mount options.

[Valtasaar]

Forgot to clarify. This issue appeared after update Windows and reinstall WSL. I did not make any changes with $PATH or other system settings.

[davidalejandroaguilar]

This is happening to me too on Ubuntu 16.04.3 LST Xenial, didn't happen on previous (I think it was Trusty). Any ideas of how to silence this? #81 chmod doesn't seem to be working.

[therealkenc]

Forgot about this one. Work-arounds are in the comments above. This is linux-behavior (by-design Ruby). The reason you were not seeing this previously is that /mnt/c didn't use to be in your $PATH before you upgraded. It was added with the interop improvements. You would get the same error on Real Linux with a 777 directory in your path. You can't chmod a ntfs-3g directory on Real Linux, same as DrvFs on WSL. Thanks @shevegen for the detailed explanation.

[davidalejandroaguilar]

Thanks for the reply.

I'm not really building a gem or in control of the console output, I'm using Rails and this message pops up whenever I start the server, create a migration, etc.

Would you know of any way to silence the message if chmod on /mnt/c is not possible? Not really sure that removing /mnt/c from $PATH is a good choice. Or is that the only way?

[therealkenc]

I don't know enough about Rails to tell you (mostly I can spell Rails). Maybe someone who knows more will jump in, but you might get more hits in that community than here. I agree entirely that forgoing /mnt/c in your $PATH is a pretty big hammer if you like the interop feature, especially since just living with the warning is a viable if annoying option.

[abulasar4all]

Run 'chmod -R o-w /usr/local/m'.
After running above command if you try to generate model or controller using rails command you will get 'dont know how to build task rails'. For this run 'bundle install --binstubs'.

[lucascaton]

Any news on this?

[dayne]

Just an FYI for others running into this problem and finding this closed issue...

You can remove all those /mnt/c paths from your $PATH with the following line:

export PATH=`echo $PATH | tr ':' '\n' | awk '($0!~/mnt\/c/) {print} ' | tr '\n' ':'`

If you add that line to your .bashrc file it will automatically be run ... do that only if you are sure you don't want those windows bin dirs in your path. You can always remove the line to bring them back.

[Amazon-Dev12]

Just an FYI for others running into this problem and finding this closed issue...

You can remove all those /mnt/c paths from your $PATH with the following line:

export PATH=`echo $PATH | tr ':' '\n' | awk '($0!~/mnt\/c/) {print} ' | tr '\n' ':'`

If you add that line to your .bashrc file it will automatically be run ... do that only if you are sure you don't want those windows bin dirs in your path. You can always remove the line to bring them back.

Do I want those bin dirs in my path? What could break if those are removed? Just curious, thanks

[dayne]

Doing this won't break anything related to the Linux side. It just removes access to the windows applications from the active path.

You can test it out by running the export PATH line in an open shell. When you close the shell and re-open and you'll be back to the default behavior w/o any changes.

[pgl]

This can be resolved by adding the following to /etc/wsl.conf:

[automount]
options="metadata,umask=0033"

[mcascone]

This can be resolved by adding the following to /etc/wsl.conf:

[automount]
options="metadata,umask=0033"

This doesn't work for me.
Windows OS Build 15063.1805 (upgrades hamstrung by corporate IT)

my specific error is

~$ knife role list
/opt/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-12.21.26/lib/chef/mixin/path_sanity.rb:25: warning: Insecure world writable dir /mnt/c/opscode/chefdk/bin in PATH, mode 040777

[andrew-koster-]

Why is this closed? It's not solved.

/etc/wsl.conf doesn't even exist. I tried creating it and adding the automount thing, but that doesn't work either.

[andrew-koster-]

How is it possible that even with root permissions, I can't fix any of the permissions on /mnt/c ? I get "Permission denied" errors when I try.

[meelos]

Yeah experiencing this issue trying to bundle install a rails gemfile. Nothing seems to work from above.
Just keep getting "warning: Insecure world writable dir /mnt/c/ProgramData in PATH, mode 040777"
WSL2 with Ubuntu 18.04

[obrien-k]

Same sort of error when trying to install brew, which is popular and would be nice to have on Windows.

[jmdfm]

I just ran into this on WSL2 and Windows build Build 18999 and can confirm that creating a /etc/wsl.conf (which didn't exist and I had to create it via sudo) with the following works and removes this warning message:

[automount]
enabled=true
options="metadata,umask=0033"

I had to restart in order to get it to take.