Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chmod doesn't work? #81

Closed
gencoimports opened this issue Apr 8, 2016 · 56 comments
Closed

chmod doesn't work? #81

gencoimports opened this issue Apr 8, 2016 · 56 comments
Labels

Comments

@gencoimports
Copy link

chmod doesn't seem to edit permissions. The command registers fine in bash, but the changes are not made to the actual files.

@dethoma
Copy link

dethoma commented Apr 8, 2016

Is this inside /mnt/ NTFS drives? We explicitly do not change Windows ACLs on them today based on chown/chmod. These commands work with full fidelity on the Linux filesystem in the lxss folder.

@gencoimports
Copy link
Author

I'm a bit of a noob, so bear with me. But if I understand this correctly, chmod won't work on any files contained in the /mnt/[ntfs dive] partitions? BUT will work fine in the /.../lxss folders and/or other linux systems?

*EDIT: chmod does seem to work just fine when I ssh into my server and edit files/folders there. Just doesn't work on Windows C-drive,D-drive, etc.

@dethoma
Copy link

dethoma commented Apr 8, 2016

Yes you are correct, it works inside the lxss folders where we have /home folder etc and we adhere to strict Linux rules. For files in the /mnt/c/* locations we do not want to modify Windows ACLs.

@vyv03354
Copy link

I understand you do not want to map permissions to NTFS ACLs. If WSL does it at all, it should map POSIX ACLs rather than traditional permissions.

But could you at least map writable permissions to read-only attributes under /mnt/c/? It will fail to write read-only files anyway, but Linux apps can't tell it will fail until it actually tries to write the file because the permission pretends to be writable.

@justinSelf
Copy link

Is there any plan in the future to allow chmod to "work" on /mnt/c?

There are several tools that create conventions around the permissions of a file to determine how to handle it.
Ansible, for one.

@sunilmut
Copy link
Member

We will be tracking\prioritizing which features to light up next by looking at the feedback provided at the wpdev portal. We appreciate your feedback and please make sure to provide it through the wpdev portal as well.

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo

@AnneTheAgile
Copy link

@bakeiro
Copy link

bakeiro commented Aug 16, 2016

i think this is bad structured, example: for install "x" app i must have 755 permision, okay so try to use chmod but only works on lxss directory so... move the app from windows to lxss directory to use chmod buuut from linux i simply can´t see files when comes from windows directory only when are created from linux.So whats next? i simply cant use chmod in /mnt/c and simply cant see files in lxss directory

@bitcrazed
Copy link
Contributor

This isn't a priority for us and we have no plans to support this ask in the appreciable future. Closing for now.

If you'd like us to reconsider, please find/upvote this issue on UserVoice and share a little background on your scenarios.

@mufumbo
Copy link

mufumbo commented Feb 21, 2017

many things that people use every-day won't ever work:


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/mnt/c/Users/test/web/web.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /mnt/c/Users/test/web/web.pem

Any advice, rather than duplicating our files in a filesystem that is difficult to edit?

Just to make it simpler for people to upvote:
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13309479-emulate-posix-compliant-filesystem-permissions

@erdemece
Copy link

erdemece commented Mar 5, 2017

If this is ubuntu on bash truly for helping developers to do more on windows this is really must do.

I use vagrant on windows and I can work in www folder on my windows folder system. So, I don't have to use terminal to write my code. I use sublime text and have Projects folder and I keep all my www virtual server folders in there. this makes it easier to develop.

You can't do this with ubuntu on bash. this alone makes it no developer friendly at all.

@aseering
Copy link
Contributor

aseering commented Mar 5, 2017

@erdemece -- I do that all the time; it works great for me. What specific problems are you seeing? Please include (by copy&paste) the exact command-line command that you are running and the exact text of the error message that you are seeing.

For what it's worth, I as a WSL user have heard a lot of people complaining about this. In my personal experience, around 15-20% of them have a very real use case, something that they can't do on WSL right now. Those are real people with real use cases, so in my opinion this should absolutely get fixed. But for 80-85% of the use cases I've heard, devs actually can do exactly what they want to do with either a very minor change to their workflow / a simple trick that they just didn't know about, or by changing a setting in some application, or sometimes WSL is actually working just fine and they just forgot to configure some piece of their dev environment on the new machine.

@computergeek125
Copy link

Example use case: SSH on both WSL and something else like Cygwin or PuTTY. I can symlink my Windows .ssh directory into the WSL system (cd ~; ln -s /mnt/c/Users/me/.ssh. I don't have my Windows box in front of me so I can't double-check that path). With this setup, my SSH config and keys would be identical and I don't have to copy duplicate keys to each host.

Solution idea: perhaps instead of just globally setting NTFS permissions to 755, you could instead set the NTFS permissions to the current umask value. With a umask of 755, it would be identical to the current behavior. But, you could then set a umask of 700 to allow things like ssh to work.

@mufumbo
Copy link

mufumbo commented Mar 6, 2017

@aseering I'm not sure how proficient you are with bash or linux systems. Please, see my use case above.

One of the most trivial things you might want to do with bash is to use a program called "ssh" to open other linux boxes on the cloud. With the current windows-on-ubuntu setup, you can't use ssh properly, since you can't use chmod command to configure your ssh server keys.

This means you can't execute BASH scripts that connect to your servers and automate things, like deploying new code to production or development servers that are hosted on another machine. (on amazon for example).

To clarify: this isn't a simple workflow change, like using "putty" instead of "ssh", but it undermines the whole reason to have ubuntu-on-windows. One of the most useful things to have bash, is to be able to run bash programs to automate "ssh" commands.

Hope it helps you to understand. thanks!

@aseering
Copy link
Contributor

aseering commented Mar 6, 2017

@mufumbo -- yep, your use case definitely makes sense to me. Ditto for @computergeek125 ; it sounds like a very similar use case. I use ssh all the time; I'm quite familiar :-)

As a workaround, could you simply have two copies of your SSH keys, one in a Windows-accessible directory and one in Linux? Or do you change them often enough, or have enough of them, that this would be problematic? If (for example) you have one key and you rotate it once per year, will the amortized cost of copying it to two places be prohibitive? Of course, if you have lots of keys and/or use a key-management tool, then you're right that there is (to my knowledge) no great workaround right now.

I didn't mean to refer to you in my original comment. I meant to refer specifically to @erdemece , whose concern seemed to be (if I understand it correctly) developing a Web app using Windows tools while serving it via Apache. Apache is, generally speaking, happy to serve any files that it has access to and that are within its DocumentRoot (or that Apache is otherwise configured to serve). If Apache isn't seeing the files, I would ask whether Apache is pointing directly at DrvFs or if it's pointing at a symlink. In the latter case, I'd ask whether Apache has FollowSymlinks set correctly. If it's pointing directly at DrvFs, I would ask whether Apache's own (Allow/Deny) permissions are set up to allow it to serve from that directory. I can keep going for a while with the decision tree here -- basically, @erdemece 's particular report was very broad; the limited information provided so far could be pointing to any of several WSL limitations as well as a variety of ordinary system misconfigurations. I just want a more-precise bug report :-)

@aseering
Copy link
Contributor

aseering commented Mar 6, 2017

@computergeek125 -- that's an interesting idea, but, a concern: Linux permissions have two aspects. The umask corresponds to the second aspect -- what is the file's owner/group allowed to do with the file? The first is, who is the file's owner? DrvFs doesn't track file ownership either; everything is owned by root. If everything in DrvFs inherited root's default umask, then you would not be able to edit files in DrvFs as an ordinary Linux user, which I think would be frustrating to a lot of people. And while most (not all!) WSL installations do have a default non-root user account, it's common to create additional users. So, if WSL picked one user account to own the files, this would create problems for the other user accounts.

I suppose DrvFs could report that files are always owned by the "current user" -- whatever process is asking, it checks what user that process is running as, and reports files as being owned by that user. But that seems to me like a risky level of magic...

@computergeek125
Copy link

Risky magic indeed. I temporarily forgot that aspect.

@mufumbo
Copy link

mufumbo commented Mar 7, 2017

@aseering yes, i tried those work-arounds, but in the end of the day the idea was to use windows for UI management and ubuntu as bash. I found it painful/impossible to have to deal with filesystems that can't communicate. (it was easier to install linux in a virtualbox machine and use bash from there, which is too painful too)

Do you think it would be possible for the ubuntu subsystem to have it's custom chmod's for windows FS in memory? That would solve many problems.

@aseering
Copy link
Contributor

aseering commented Mar 7, 2017

@mufumbo -- I'm not a WSL developer; I'm just a user. (WSL devs usually have the "Member" or "Owner" tags on their posts.) So, as to whether the permissions could be kept in memory (presumably in lxss somewhere so that they would be scoped to the current user) -- I'm sure it would be technically feasible, as long as you don't have too many files, but I'm not in a position to do it :-)

As a user, I'm trying to do something that's very similar to my reading of your description above, and it works great for me. Small up-front cost; zero ongoing cost. Vastly easier for me than a VM. But it clearly doesn't work well for you. So it seems to me that there's some difference that explains why things work for me and not for you. Given that there fundamentally isn't one single simple clear way to map Linux permissions to DrvFs (do they affect Windows permissions?, do different Windows users' bash installs see each others' permissions?, etc), I think there's a reasonable chance that whatever you're hitting could be relevant to the design decisions that the WSL team might decide to make in the future.

@mufumbo
Copy link

mufumbo commented Mar 8, 2017

@aseering thanks so much for your help and empathy!

I was so excited when I saw BashOnWindows that I bought a 32gb ram $3300 machine and decided to try windows. Unfortunately, it's not there yet and I have to go back to the lame apple hardware.

@hendorog
Copy link

hendorog commented Mar 8, 2017

Simple use case:
Without chmod support it isn't possible to login to an Amazon instance. That requires ssh -i support.
I use the same script on OSX and linux, but it doesn't work on Windows because of this limitation.

@aseering
Copy link
Contributor

aseering commented Mar 8, 2017

@hendorog -- SSH keys are actually discussed a bunch in this thread already, including workarounds. I use AWS all the time from WSL by placing my keys in ~/.ssh. Could you elaborate on what about your particular situation makes those workarounds difficult for you? For example, do you need to store your keys alongside your script, and it would be annoying to (for example) place them in ~/.ssh and symlink them to the directory of your script? (ssh checks file permissions, not symlink permissions.)

( @mufumbo -- no problem; sorry I can't actually fix this. Ooh, that's a nice machine. It's probably poor form on a Windows forum, but I'm tempted to suggest making a Hackintosh :-) )

@hendorog
Copy link

hendorog commented Mar 8, 2017

@aseering Yep the workarounds work, but workarounds are just that. The issue is that scripts using AWS would all need to be modified to support Windows, or symlinks used etc.

ssh is just such a fundamental tool in unix world, AWS is very widely used, and key based login is more the norm than the exception now.

Also, off the top of my head I thought from many years ago NTFS was posix compatible. So I thought implementing chmod/chown would be possible. Implementation left as an exercise for the reader of course :)

Edit: followed the link posted above, this was marked COMPLETED yesterday but comments suggest it has not fixed the issue.
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13309479-emulate-posix-compliant-filesystem-permissions

@matthewrk
Copy link

matthewrk commented Mar 10, 2017

Another use case is web developers running webapps under WSL but editing in Windows, which I assume is extremely common unless I'm doing something wrong/weird. To do this the source has to be under /mnt/c/some/directory which is all root:root. So I either have to run the webapp as root or my app has no write access to its working directory.

@aseering
Copy link
Contributor

aseering commented Mar 10, 2017

@hendorog -- one challenge with using NTFS POSIX ACLs is, who would own the file? NTFS ACLs are global to all users on the machine. But each Windows user account has its own separate set of Linux users.

(I for one would love to see real NTFS-native POSIX ACLs be used here, and I can think of a few different ways to do that. Just stating one place in which the concepts don't map in the way that one might like.)

@matthewrk -- it's true that the files are owned by root, but it's not necessarily true that only the owner of a file can edit that file. In this specific case, the files have permissions 0777, which means that all users can edit the file regardless of who owns them.

@matthewrk
Copy link

@aseering you're correct! It was slightly blurred for me because I'm using rsync to workaround issue #873 which wasn't copying the permissions. With that knowledge though I should be able to fix it, thanks very much.

@tara-raj
Copy link

Marking this closed as per #81 (comment)

@zanona
Copy link

zanona commented Jun 4, 2018

Thanks, guys. I tested, and it worked well under sudo.
Although I need to open Ubuntu, stop all processes that are using /mnt/c and then restart with

sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata

This needs to be done every time an Ubuntu terminal is opened.

By any change will this be a default in the future, or any way to make this persistent across sessions?

Thanks again.

@onomatopellan
Copy link

@zanona If you are on build 17134 you can use wsl.conf. https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/

@zanona
Copy link

zanona commented Jun 4, 2018

That's awesome! Thanks, @onomatopellan. It worked just as expected 😉

@ghost
Copy link

ghost commented Jun 27, 2018

Wait, what goes in wsl.conf? To do @zanona's thing automatically?

@onomatopellan
Copy link

@monkeysuffrage with a linux editor create a /etc/wsl.conf file with this content

[automount]
enabled = true
options = "metadata"
mountFsTab = false

Close the Ubuntu window and open again. This will enable metadata for every fixed drive.

@dragGH102
Copy link

dragGH102 commented Aug 1, 2018

I have tried (build 1803) both - with and without - the wsl.conf suggested by @onomatopellan but chmod just doesn't work (does nothing)

Note I'm using Debian, not Ubuntu but they're fundamentally the same afaik...

@onomatopellan
Copy link

onomatopellan commented Aug 1, 2018

@dragGH102 Just tried Debian WSL on 1803 and it works. What's your output of cat /etc/wsl.conf ?

@dragGH102
Copy link

@onomatopellan weird indeed. There was a typo but even after changing it to

[automount]
enabled = true
options = "metadata"
mountFsTab = false

(output of cat)

I still get the issue. I have restarted Debian app (not Windows - unsure whether that's necessary)

@onomatopellan
Copy link

@dragGH102 When wsl.conf is applied you can see the metadata option on mount output. You need to close every WSL open window and on Task Manager kill every "init" picoprocess you find. Seems some people need to reboot Windows in order to get wsl.conf working but I think it's because some WSL picoprocess remains on memory.

@dragGH102
Copy link

@onomatopellan thanks for clarifying. I can confirm that after a restart, it works

@Hi-Angel
Copy link

Ah, nvm, per last comments in this issue it seems to be solved. Probably worth commenting on the user-voice page as well, sorry for the noise.

@theAkito
Copy link

To Everyone Arriving here from Google

To clarify and summarize the solution to the original problem of this issue, I will explain how to apply the fix without restarting your computer.

  1. Open /etc/wsl.conf with your favourite text editor.
  2. Paste the following into it:
[automount]
enabled = true
options = "metadata"
mountFsTab = false
  1. Close all WSL windows!
  2. Open PowerShell.
  3. List your WSL distributions:
wsl --list
  1. Pick the one you want to fix. We select "Debian" as an example.
  2. Terminate the Debian WSL instance:
wsl --terminate Debian
  1. Open a new Debian WSL window. It should load for a couple of seconds, which already indicates that the whole WSL was terminated, before.
  2. The fix should be applied now. If it still does not work, repeat all above steps and make absolutely sure, that no WSL windows remain open when applying the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests