Unable to change file permissions on Ubuntu Bash for Windows 10

Question

I was trying to use an ssh instance and I received the following error, which is odd since I tried to change the permission using chmod, but that didn't seem to work as permissions were still 777:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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).

I opened git bash and was able to SSH into my instance with no problem, and permissions were not 777 as well.

For everyone not able to get the wsl.conf options working, you have to restart the LxssManager service. Closing the WSL instances is not good enough sometimes. — Brain2000, Jul 10 '20 at 13:29

score 103 · Accepted Answer · answered Jul 27 '18 at 07:52

103

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.

answered Jul 27 '18 at 07:52

nilskp

1,146
1
8
4

7

This is the absolute right answer! – Arif Amirani Aug 05 '18 at 14:36
7

Does 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 Jan 28 '19 at 06:19
@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 Jan 28 '19 at 16:10
@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 Jan 29 '19 at 00:54
1

@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 Jan 29 '19 at 23:38
@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 Jan 30 '19 at 00:20
@Ash, ah, makes sense. – nilskp Jan 30 '19 at 00:51
I had to restart my machine after the changes. – Robin De Schepper May 31 '21 at 09:03

Basil A · Answer 2 · 2021-07-07T10:32:39.463

31

The correct way to handle this:

Create /etc/wsl.conf with 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
Close all WSL terminals and open a new one
Restart your machine (as indicated by some comments)

Now you are all set; changing permissions of a file in Windows from /mnt/c/ will be reflected, and mounted, correctly within WSL on startup via the metadata option.

edited Jul 07 '21 at 10:32

answered Jan 10 '19 at 11:44

Basil A

530
6
7

4

Does 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 Jan 28 '19 at 06:18
fmask must be set to 111. See https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/ – Arunprasad Rajkumar Apr 22 '19 at 09:09
1

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 May 19 '19 at 10:22
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 May 19 '19 at 10:46
6

This worked for me ONLY after I restarted my machine. – K F Jul 29 '20 at 02:07
This is likely because WSL seems to persist a little while after exiting it's shell. – Webber Nov 13 '21 at 16:24

erobertc · Answer 3 · 2018-05-17T17:05:34.043

25

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

edited May 17 '18 at 17:05

answered May 17 '18 at 16:59

erobertc

593
4
10

13

There are at least 3 pages to that discussion. You really should quote the information you feel is relevant to the author. – Ramhound May 17 '18 at 18:23
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 May 17 '18 at 18:53
2

@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 May 17 '18 at 19:09
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 May 17 '18 at 21:30
2

Not 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/` directory, and then `chmod` worked as expected. – Ash Jan 28 '19 at 06:12
changing the file location to Linux file system folders worked for me. – Rajitha Fernando Oct 23 '19 at 06:10
This is a weird one - for some reason my path was moved from /c/Users/username to /mnt/c/Users/username after a reboot. I'm still not sure how that could have happened on it's own. I didn't have any issues until I tried to chmod and now it does nothing. – Geoff Maddock Jul 24 '20 at 18:16
Thanks @erobertc . This worked for me. And also made me aware of the difference in WSL between mounted folders and normal linux folders. – blispr Jun 11 '21 at 00:08
@Ash: I'm facing the same problem, but for me I can't change the file permissions in a folder that is in my Linux home directory itself. It's in my ~/.aws directory. Again, just like you changing it to 400 works but changing to 600 doesn't (actually changing it to 600 effectively changes it to 777 I think). Any other ideas? – Piyush Soni Sep 05 '22 at 06:47

Salvioner · Answer 4 · 2019-12-12T16:17:59.090

10

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

edited Dec 12 '19 at 16:17

answered Dec 12 '19 at 15:36

Salvioner

201
2
6

2

Thank you! This is the only thing that worked for me after hours of research – AlexT Jan 04 '21 at 05:15
2

+1 for ingenuity. But the above solution by @Basil also worked, after rebooting (required) – Brent Faust Feb 02 '21 at 22:18
worked for me, thanks – user1007727 Nov 16 '22 at 13:28

score 4 · Answer 5 · edited Jul 16 '22 at 19:12

4

I would like to add to @basilA's answer, because it's not that easy to create a /etc/wsl.conf file, especially since I kept getting:

-bash: /etc/conf.wsl: Permission denied

even if I ran commands with sudo. Anyway, the trick is to change to the root user.

So, from a regular command prompt, type the following commands:

wsl
sudo su

cat > /etc/wsl.conf << EOF
[automount]
options = "metadata"
EOF

edited Jul 16 '22 at 19:12

jdunning

505
5
8

answered May 04 '21 at 09:20

JBSnorro

237
1
9

1

The `sudo su` bit was what was missing from all the explanations I'd seen. – jdunning Jul 16 '22 at 01:44

score 3 · Answer 6 · answered Aug 02 '19 at 14:26

3

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

answered Aug 02 '19 at 14:26

ashwini

41
2

nothing above worked for me; thanks for this!! – awerchniak Jun 12 '22 at 19:47

score 0 · Answer 7 · answered Sep 30 '22 at 14:33

0

I had the issue that my files were stored on an external hard drive which happend to be formated in exFAT. Well you cannot change permissions for files on any FAT and if you try it may end in weird results. So you have to copy your files to a hard drive formated in NTFS and try again. (btw: there is also no security tab in the file properties on FAT)

answered Sep 30 '22 at 14:33

Lakonu

1

1

As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Sep 30 '22 at 14:42

score 0 · Answer 8 · answered Feb 27 '23 at 11:42

NONE of those answers worked for me but

opening a Windows PowerShell Terminal with Administration rights and then
opening an Ubuntu tab and
executing chmod 666 /path/to/the/file/I/want (feel free to change permissions number)

did the trick

(1. right-click, 2. right-click, 3. left-click)

good luck with this annoying issue, hope this will fix it

score -1 · Answer 9 · answered Sep 21 '21 at 05:58

-1

You cannot give 777 permission to *.pem file

Use chmod 400 filename.pem

it will fixed the issue

in some system you can use chmod 600 filename.pem

answered Sep 21 '21 at 05:58

Rockinroll

101
2

2

This doesn't answer the question. – Toto Sep 21 '21 at 08:20
When i face the same situation i just copy the pem file in window linux subsystem and run this command it resolved my issue – Rockinroll Sep 22 '21 at 09:26

Unable to change file permissions on Ubuntu Bash for Windows 10

9 Answers9

Linked

Related