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.
windows-10 ubuntu bash ssh windows-subsystem-for-linux
asked May 17 '18 at 16:51
iiiiii
12815
add a comment |
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.
windows-10 ubuntu bash ssh windows-subsystem-for-linux
asked May 17 '18 at 16:51
iiiiii
12815
1
So which update? What happens if you roll it back?
– DavidPostill♦
May 17 '18 at 19:11
1
Similar to this superuser.com/q/1321072/726810
– Biswapriyo
May 17 '18 at 21:11
add a comment |
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.
windows-10 ubuntu bash ssh windows-subsystem-for-linux
asked May 17 '18 at 16:51
iiiiii
12815
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.
windows-10 ubuntu bash ssh windows-subsystem-for-linux
windows-10 ubuntu bash ssh windows-subsystem-for-linux
asked May 17 '18 at 16:51
iiiiii
12815
asked May 17 '18 at 16:51
iiiiii
12815
edited Aug 7 '18 at 15:57
iii
asked May 17 '18 at 16:51
iiiiii
12815
asked May 17 '18 at 16:51
iiiiii
12815
asked May 17 '18 at 16:51
iiiiii
12815
12815
1
So which update? What happens if you roll it back?
– DavidPostill♦
May 17 '18 at 19:11
1
Similar to this superuser.com/q/1321072/726810
– Biswapriyo
May 17 '18 at 21:11
add a comment |
1
So which update? What happens if you roll it back?
– DavidPostill♦
May 17 '18 at 19:11
1
Similar to this superuser.com/q/1321072/726810
– Biswapriyo
May 17 '18 at 21:11
1
1
So which update? What happens if you roll it back?
– DavidPostill♦
May 17 '18 at 19:11
So which update? What happens if you roll it back?
– DavidPostill♦
May 17 '18 at 19:11
1
1
Similar to this superuser.com/q/1321072/726810
– Biswapriyo
May 17 '18 at 21:11
Similar to this superuser.com/q/1321072/726810
– Biswapriyo
May 17 '18 at 21:11
add a comment |
3 Answers
3
active
oldest
votes
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 7:52
nilskpnilskp
21624
3
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6: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 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 anychmoddone via WSL won't be observed?
– Ash
Jan 29 at 0:54
1
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
|
show 3 more comments
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
answered May 17 '18 at 16:59
erobertcerobertc
26218
2
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
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
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
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
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
|
show 2 more comments
The correct way to handle this:
- Create a file named
/etc/wsl.confand 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.
answered Jan 10 at 11:44
Basil ABasil A
20015
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6:18
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1323645%2funable-to-change-file-permissions-on-ubuntu-bash-for-windows-10%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 7:52
nilskpnilskp
21624
3
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6: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 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 anychmoddone via WSL won't be observed?
– Ash
Jan 29 at 0:54
1
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
|
show 3 more comments
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 7:52
nilskpnilskp
21624
3
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6: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 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 anychmoddone via WSL won't be observed?
– Ash
Jan 29 at 0:54
1
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
|
show 3 more comments
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 7:52
nilskpnilskp
21624
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 7:52
nilskpnilskp
21624
answered Jul 27 '18 at 7:52
nilskpnilskp
21624
answered Jul 27 '18 at 7:52
nilskpnilskp
21624
answered Jul 27 '18 at 7:52
nilskpnilskp
21624
21624
3
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6: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 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 anychmoddone via WSL won't be observed?
– Ash
Jan 29 at 0:54
1
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
|
show 3 more comments
3
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6: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 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 anychmoddone via WSL won't be observed?
– Ash
Jan 29 at 0:54
1
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
3
3
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
This is the absolute right answer!
– kontinuity
Aug 5 '18 at 14:36
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 at 6:19
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 at 6: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 at 16:10
@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 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 at 0:54
@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 at 0:54
1
1
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
Worked perfect for me. Thanks a ton @nilskp
– Devoloper250
Feb 3 at 8:57
|
show 3 more comments
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
answered May 17 '18 at 16:59
erobertcerobertc
26218
2
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
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
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
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
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
|
show 2 more comments
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
answered May 17 '18 at 16:59
erobertcerobertc
26218
2
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
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
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
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
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
|
show 2 more comments
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
answered May 17 '18 at 16:59
erobertcerobertc
26218
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
answered May 17 '18 at 16:59
erobertcerobertc
26218
edited May 17 '18 at 17:05
answered May 17 '18 at 16:59
erobertcerobertc
26218
answered May 17 '18 at 16:59
erobertcerobertc
26218
answered May 17 '18 at 16:59
erobertcerobertc
26218
26218
2
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
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
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
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
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
|
show 2 more comments
2
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
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
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
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
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
2
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
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
1
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
The thing was that perviously, I was able to ssh into my instance with no problem. This only started happening today
– iii
May 17 '18 at 18:42
1
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
@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
1
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
May 17 '18 at 19:09
@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
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
@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
|
show 2 more comments
The correct way to handle this:
- Create a file named
/etc/wsl.confand 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.
answered Jan 10 at 11:44
Basil ABasil A
20015
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6:18
add a comment |
The correct way to handle this:
- Create a file named
/etc/wsl.confand 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.
answered Jan 10 at 11:44
Basil ABasil A
20015
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6:18
add a comment |
The correct way to handle this:
- Create a file named
/etc/wsl.confand 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.
answered Jan 10 at 11:44
Basil ABasil A
20015
The correct way to handle this:
- Create a file named
/etc/wsl.confand 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.
answered Jan 10 at 11:44
Basil ABasil A
20015
answered Jan 10 at 11:44
Basil ABasil A
20015
answered Jan 10 at 11:44
Basil ABasil A
20015
answered Jan 10 at 11:44
Basil ABasil A
20015
20015
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6:18
add a comment |
Does not work for me. I did exactly as you suggest, but permission set usingchmodstill do not reflect when doing als -al. Strangely enough (and this was also the case prior to doing this change), certainchmodvalues work while others don't. For e.g, 0600 has no effect but 0400 changes it to -r-xr-xr-x.
– Ash
Jan 28 at 6:18
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 at 6:18
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 at 6:18
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1323645%2funable-to-change-file-permissions-on-ubuntu-bash-for-windows-10%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
So which update? What happens if you roll it back?
– DavidPostill♦
May 17 '18 at 19:11
1
Similar to this superuser.com/q/1321072/726810
– Biswapriyo
May 17 '18 at 21:11