104

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
joe5
  • 1,101
  • 2
  • 8
  • 10
  • 6
    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. – Eryk Sun Oct 06 '17 at 17:43
  • MINGW32:/c/Users/joe/working2 – joe5 Oct 06 '17 at 18:16
  • "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. – Eryk Sun Oct 06 '17 at 18:35
  • 1
    Have you also tried using `sudo`? – ifconfig Oct 07 '17 at 21:02
  • 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. – joe5 Oct 09 '17 at 12:02
  • @ifconfig when I run sudo i get an error "bash: sudo: command not found". – joe5 Oct 09 '17 at 12:03
  • What system are you on? I am really surprised there is no sudo. – ifconfig Oct 09 '17 at 14:28
  • 1
    @ifconfig I am on windows using the bash that comes with GIT. – joe5 Oct 09 '17 at 17:32
  • 5
    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. – Eryk Sun Oct 09 '17 at 21:09

3 Answers3

159

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

Captain Man
  • 6,997
  • 6
  • 48
  • 74
Chao
  • 1,771
  • 1
  • 11
  • 12
48

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
Amade
  • 3,665
  • 2
  • 26
  • 54
  • 1
    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. – Weekend May 09 '18 at 12:14
  • 2
    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`. – Jean Paul Aug 12 '21 at 14:34
3

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?

hko
  • 548
  • 2
  • 19