chmod WSL (Bash) doesn't work [closed]
Asked Answered
K

3

105

Running bash on windows 10, the simple syntax below works when I SSH to my webserver, but not when I exit out and am on my local machine. It doesn't give me an error, but I can see permissions are unchanged. I have to checked that I am set up as an administrator on my computer. Is this an error or is this just a consequence of the local operating system being windows? IF the later, it makes me question the value of using bash on windows if common operations such as this won't work.

$chmod 644 filename 
Kelbee answered 6/10, 2017 at 16:35 Comment(9)
What's the path of the file you're trying to modify? Is it on a drvfs mount such as "/mnt/c"? If so, Unix permissions hardly apply to a file in a Windows filesystem. All it can control is the read-only file attribute, which can be set by removing write access for everyone, e.g. chmod 555 filename. Implicitly everyone will always have read and execute access, since no Windows file attributes correspond to that.Hexosan
MINGW32:/c/Users/joe/working2Kelbee
"MINGW32:/c" looks like MSYS bash to me (e.g. from Git), not WSL bash. It's similar, except it tries to be smarter about what's executable in terms of file extensions like .EXE and .DLL and the PATHEXT extensions, and it controls the read-only flag only via the user permissions instead of requiring it unanimously for user, group, and other.Hexosan
Have you also tried using sudo?Expecting
And yes, @eryksun, you are correct, I did install bash as a part of GIT, but didn't realize there was a difference between it and WSL. Thanks for clarifying that.Kelbee
@Expecting when I run sudo i get an error "bash: sudo: command not found".Kelbee
What system are you on? I am really surprised there is no sudo.Expecting
@Expecting I am on windows using the bash that comes with GIT.Kelbee
The MSYS environment is bash plus the typical command-line programs found in Unix, built over the user-mode Windows API. In contrast, the Linux subsystem in Windows 10 uses a kernel driver and pico processes that directly execute ELF binaries, including sudo. Still, it can't enable an NTFS volume mounted via drvfs to work like a native Linux filesystem. System calls such as chmod work as well as can be expected. Native Linux filesystem support is provided by the lxfs filesystem used for "/", which is persisted to disk in the user's %LocalAppData%\lxss folder, but not for use in Windows.Hexosan
I
172

To enable changing file owners & permissions, you need to edit /etc/wsl.conf and insert the below config options:

[automount]
options = "metadata"

Do this inside the WSL shell, potentially needing sudo to edit/create the file.

This may require restarting WSL (such as with wsl --shutdown which is a Windows command, not one within WSL) or the host machine to take effect. This has been possible since 2018:

You can now set the owner and group of files using chmod/chown and modify read/write/execute permissions in WSL. You can also create special files like fifos, unix sockets, and device files. We’re introducing new mounting options with DrvFs for projecting permissions onto files alongside providing new Linux metadata on files and folders.

[cite: Microsoft Dev Blog]


You can also temporarily re-mount a drive with the following commands:

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

...but please note, the command only takes effect in session scope. If you exit current bash, you'll lose your settings (credit: answerer Amade).


Reference:

Automatically Configuring WSL

Irrawaddy answered 14/6, 2018 at 11:43 Comment(8)
I used enabled = true instead of enable = trueCherycherye
@Irrawaddy Chmod/Chown link is broken in the answer, should point to blogs.msdn.microsoft.com/commandline/2018/01/12/… :-)Ouidaouija
"enabled" is superfluous. This option is "true" by defaultMidlands
I had to restart my machine after saving /etc/wsl.conf in order for the changes to take place.Kempis
Need to run wsl --shutdownDepriest
Thanks @Depriest and @HA3IK; have edited this essential context into the answer.Flack
This still did not let me change permissions. I'm getting Permission deniedPrey
The file /etc/wsl.conf did not exist, so I created it, and it worked after restart. Thanks!Interaction
P
51

There was an update to WSL recently (source), which lets you change permissions to files (Insider Build 17063).

All you have to do is to run:

sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata
Pentheam answered 17/2, 2018 at 12:19 Comment(2)
Remember to check your os version before sudo umount. My computer is managed by my organization and locked on 1709(16299.402). When remount it says wrong fs type, bad option, bad superblock on D:. Luckily, a restart of bash fixes it.Motheaten
The problem with this solution is that it mounts the c drive as root. To have files owned by me instead of root I had to do sudo mount -t drvfs C: /mnt/c -o metadata,gid=1000,uid=1000.Rimbaud
R
5

Both Amades and Chaos answers are correct. But it only works for local drives not for mapped network drives. Z: is one of my network drives. Same operation on /mnt/c/Users/xxx/ works fine.

$sudo mount -t drvfs Z: /mnt/z -o metadata
$touch test
$chmod +w test
 chmod: changing permissions of 'test': Operation not permitted

This is a known issue, see drvfs: metadata (chmod\chown) possible for mounted SMB drives?

Riverside answered 16/12, 2019 at 23:55 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.