Unable to change file permissions on Ubuntu Bash for Windows 10

I was trying to use an ssh instance and I recieved this error:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'privkey.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "privkey.pem": bad permissions
Permission denied (publickey).

Which is odd. I tried to change the permission using the 'chmod' command, but that didn't seem to work. The bash gave the impression that the command registered, but I checked the permissions of the key and it was still at 777. I opened my git bash and I was able to ssh into my instance with no problem, and the permissions were not 777 as well.

iii

Posted 2018-05-17T16:51:32.910

Reputation: 283

1So which update? What happens if you roll it back? – DavidPostill – 2018-05-17T19:11:15.897

– Biswapriyo – 2018-05-17T21:11:30.677

Answers

If you're referencing files in the Windows file system, they do not, by default, retain Linux permissions. However, there's a way to enable that. Edit or create (using sudo) /etc/wsl.conf and add the following:

[automount]
options = "metadata"

Shut down all WSL instances and restart an instance, and any chmod changes are now retained.

nilskp

Posted 2018-05-17T16:51:32.910

Reputation: 476

5This is the absolute right answer! – kontinuity – 2018-08-05T14:36:02.043

2Does not work for me. I did exactly as you suggest, but permission set using chmod still do not reflect when doing a ls -al. Strangely enough (and this was also the case prior to doing this change), certain chmod values work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x. – Ash – 2019-01-28T06:19:06.740

@Ash make sure your WSL permissions doesn't contradict the Windows permission. E.g. if you mark a file read-only in Windows, it won't be writable in WSL either, as the Windows permissions overrules the WSL permissions. – nilskp – 2019-01-28T16:10:40.983

@nilskp The file is not marked Readonly under Windows and the Windows permissions for it are Full Control for SYSTEM, Administrators, and the user. If Windows permissions overrule, then by that very statement, doesn't it mean that any chmod done via WSL won't be observed? – Ash – 2019-01-29T00:54:58.043

@Ash, take a look at the options in Basil A's answer. It's possible you need one or both of those masks. I don't know enough about the issue to resolve this. – nilskp – 2019-01-29T23:38:24.903

@nilskp Please take a look at my comment to Basil A's answer, which I posted at the same time as my original comment to this answer. In short, neither approach (yours or Basil A's) works for me. Possibly because the file in question for me in under /mnt ; probably why erobertc's answer worked for me. – Ash – 2019-01-30T00:20:27.893

@Ash, ah, makes sense. – nilskp – 2019-01-30T00:51:30.057

Except that Git Bash for Windoes does not have sudo. So, this is impossible. – SherylHohman – 2019-07-23T17:31:06.873

@SherylHohman The question, and answer, is regarding the Linux subsystem for Windows, not Git Bash. – nilskp – 2019-07-31T21:06:21.150

Is the private key on your Windows filesystem (under /mnt/)? You can't modify the permissions of files on Windows's filesystem using chmod on Bash on Ubuntu on Windows. You'll have to copy the private key to your WSL home directory (~) and do it there.

Some discussion here: https://github.com/Microsoft/WSL/issues/81

erobertc

Posted 2018-05-17T16:51:32.910

Reputation: 335

5There are at least 3 pages to that discussion. You really should quote the information you feel is relevant to the author. – Ramhound – 2018-05-17T18:23:09.633

1@iii So what changed recently? Did you install any windows updates? Did you change any config files? Please edit and update your question. – DavidPostill – 2018-05-17T18:53:46.713

1@iii - Which update? Your question makes no reference to the fact it was working previously. Your question also makes no reference that you recently installed an update. I disagree with this answer, because the link is from before WSL was modified (I believe), to support what you are trying to do. Which is the reason I was pressing the author to elaborate thier answer – Ramhound – 2018-05-17T19:09:51.607

3@Ramhound, the relevant information from that discussion is paraphrased in my answer, I just added that link as a reference source. The relevant information is in the first reply there.

I didn't know that the questioner only encountered this problem after a Windows update, but they haven't said whether the key is on the Windows filesystem, so I still think that's the most likely explanation until they indicate otherwise. – erobertc – 2018-05-17T21:30:55.520

1Not sure why people are getting upset about this answer even though it presents the truth (if you think otherwise about the /mnt restriction, point to the relevant documentation in your comment). I encountered the exact same behaviour; permissions for files under the /mnt directory could not be changed using chmod. So I had to move my ssh keys to my /home/<user> directory, and then chmod worked as expected. – Ash – 2019-01-28T06:12:28.003

changing the file location to Linux file system folders worked for me. – Rajitha Fernando – 2019-10-23T06:10:32.050

The correct way to handle this:

Create a file named /etc/wsl.conf and edit it to contain the following:

    [automount]
    enabled = true
    root = /mnt/
    options = "metadata,umask=22,fmask=11"

To understand the meaning of each parameter above, please refer to this article on msdn: https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/

Close all open WSL terminal then open a new one.

Now you are all set, changing permissions of a file in windows from /mnt/c/ will be reflected correctly on the Linux Subsystem through the WSL "metadata" feature.

The WSL configuration will always mount correctly on startup of WSL.

Basil A

Posted 2018-05-17T16:51:32.910

Reputation: 300

fmask must be set to 111. See https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/

– Arunprasad Rajkumar – 2019-04-22T09:09:59.933

This answer works well for me. @ArunprasadRajkumar, fmask should not be 111 - using this removes the executable flag from all files by default (which is noted in the article that you link to) and is probably not what you want. Using fmask=11 uses executable flags from the file system by default so works well. – zelanix – 2019-05-19T10:22:01.623

To clarify my previous comment, fmask=111 removes execution rights from all files for owner, group, and anonymous users. fmask=11 removes execution rights for group and anonymous users only, while using the execution right from the file system for owner (this is probably what you want, and works well with git). umask=22 removes write rights from files and directories for group and anonymous users. – zelanix – 2019-05-19T10:46:17.340

I created an alias that gets loaded in my ~/.bashrc file and allows to unmount/remount the C:/ drive in the /mnt/c/ folder with `"metadata" permissions.

alias win-chmod="cd ~ && sudo umount /mnt/c && sudo mount -t drvfs C: /mnt/c -o metadata && cd -"

This allows me to only enable chmod when I need it, preventing unwanted changes to the mounted file system. It's just a matter of invoking

$ ls -l | grep myfile
-rwxrwxrwx 1 root root          0 Dec 12 16:34 myfile.txt
$ win-chmod
/mnt/c/Users/myself/Documents/myfolder
$ chmod 666 myfile.txt
$ ls -l | grep myfile
-rw-rw-rw- 1 root root          0 Dec 12 16:34 myfile.txt

Salvioner

Posted 2018-05-17T16:51:32.910

Reputation: 111

Copy the key file to anywhere in the Linux Sub system then change the permission and connect.

cp /mnt/path/to/key/file /home/$USER/

chmod 400 /home/$USER/key_file_name.pem

ashwini

Posted 2018-05-17T16:51:32.910

Reputation: 11