-
Notifications
You must be signed in to change notification settings - Fork 822
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
Comments
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. |
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. |
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. |
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. |
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. |
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 |
Cross-reference; user voice request for ansible as master. |
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 |
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. |
many things that people use every-day won't ever work:
Any advice, rather than duplicating our files in a filesystem that is difficult to edit? Just to make it simpler for people to upvote: |
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. |
@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. |
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 ( 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. |
@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! |
@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 :-) |
@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... |
Risky magic indeed. I temporarily forgot that aspect. |
@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. |
@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. |
@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. |
Simple use case: |
@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 ( @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 :-) ) |
@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. |
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. |
@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 |
Marking this closed as per #81 (comment) |
Thanks, guys. I tested, and it worked well under 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. |
@zanona If you are on build 17134 you can use wsl.conf. https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/ |
That's awesome! Thanks, @onomatopellan. It worked just as expected 😉 |
Wait, what goes in wsl.conf? To do @zanona's thing automatically? |
@monkeysuffrage with a linux editor create a /etc/wsl.conf file with this content
Close the Ubuntu window and open again. This will enable metadata for every fixed drive. |
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... |
@dragGH102 Just tried Debian WSL on 1803 and it works. What's your output of |
@onomatopellan weird indeed. There was a typo but even after changing it to
(output of cat) I still get the issue. I have restarted Debian app (not Windows - unsure whether that's necessary) |
@dragGH102 When wsl.conf is applied you can see the metadata option on |
@onomatopellan thanks for clarifying. I can confirm that after a restart, it works |
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. |
To Everyone Arriving here from GoogleTo clarify and summarize the solution to the original problem of this issue, I will explain how to apply the fix without restarting your computer.
|
chmod doesn't seem to edit permissions. The command registers fine in bash, but the changes are not made to the actual files.
The text was updated successfully, but these errors were encountered: