777 is the only default inside of windows directories when accessed through bash for windows.

It should work fine if you make a directory inside of WSL.

This is done through WSL.

Note: mkdir -m foo 755 foo also ignores the permissions and sets 777

If you create a directory inside the windows file system (anywhere in /mnt/c etc), it will have 777 as the file permissions because it is actually using windows file permissions.

This is not a bug. If you redo the above inside of the WSL filesystem, you will create a directory as 755.

@jakegt1
it is also 777 in ~/ by bash.exe
see #1803

This is not a bug. If you redo the above inside of the WSL filesystem, you will create a directory as 755.

If you tried this, I'd be interested to see what differences our systems have

Your example specifically shows you creating a directory inside the windows file system, you can't blame me on that one.

It seems it could actually be an issue though, I'd note that I've never noticed this happen to me so while i didn't actually go try it, directories i make inside of WSL seem to be fine.

It's probably something to do with how it creates directories outside of its own filesystem, anyway.

Other than that, it could just be incorrect masks in respect to the issue, notably in the referenced but the creator states that the directory is '755' but it's '775', which is still non standard.

The VolFs issue sounds to me like #352 . If so, the workaround would presumably be to manually set your umask to 0755, or something otherwise appropriate. If that works, this seems like a problem with that Swift test to me: While stock Ubuntu has a umask of 0755 (I think?), I have worked at a place (with a large network filesystem and many users) whose default configuration had a more-restrictive umask. WSL should strive to match stock Ubuntu's defaults, but Swift really oughtn't make assumptions about those defaults because they do get changed.

The DrvFs issue has been discussed on many tickets here, though at the moment I'm failing to find a single ticket to point at. No workaround at the moment, other than "use VolFs" :-) DrvFs simply doesn't implement permissions yet, so it exposes all files as world-writable and executable.

The default umask on Ubuntu is 0222 (http://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work)

Manually setting umask on the command line

Unfortunately, mkdir on WSL seems to ignore any umask you set:

umask 22
mkdir foo1
ls -l

Manually passing the mode on the command line

Unfortunately, mkdir on WSL seems to ignore any -m parameter you pass:

mkdir -m 755 foo2
ls -l

@hughbe -- for the sake of clarity / future readers of this thread, could you please update your last post to note that you specifically tested DrvFs and not VolFs?

The behavior that you are illustrating is as expected per other discussion on this ticket.

@hughbe
how to explain mkdir is correct through ssh?(and don't ignore the -m)
And the umask is 002 defaualt through ssh,but mkdir creat a 755 folder.

As i said in the first post, this is only an issue when you create a directory inside the windows file system, not inside WSL's own file system.

@hughbe

cd /home/a
mkdir myDir

Should give correct file permissions as set by umask.

Your example makes a directory inside the Windows file system (DrvFs), which does not support full linux permissions.

@aseering It seems that my umask by default was 0000, pretty sure i didn't set it. Should it be that by default?

Hi @jakegt1 -- for VolFs and umask issues/discussion/explanation/questions, see #352 .

@aseering I see, will keep it in mind.

The OP here was about DrvFs which doesn't support umask by design (much like Samba shares and the like). umask does work on VolFs, though there is discussion about it not being set to people's liking on startup.

I think what everyone wants to know at this point is WHERE to set umask 022 so that WSL stops creating directories with 777 instead of 755.

The improper settings BREAK things like oh-my-zsh, antigen, and other zsh stuff.

An after-the-fact solution would be to run a compaudit then find $COMMON_PATH_OF_THOSE_DIRECTORIES -type d -exec chmod 0755 {} \;

Overall, it would be nice if WSL had the umask 022 mask enabled by default and simple "put that in [insert file name here]."

Because the next problem after that would be finding out why nice(5) denies permissions to do things. It could be for the same reason. (Follow up: It's issue #1887. Just need to add unsetopt BG_NICE near the beginning of ~/.zshrc.)

This thread was really confusing. It seems several people redirected here from other threads (though not OP) and I are experiencing the issue that even in /home/our_username, mkdir still makes with 777 permissions. umask returns 0000. Was there ever a clear answer to this @therealkenc ?

Yeah there's a couple unrelated things going on here making it confusing. One is file permissions on DrvFs (/mnt/c), which are now supported in WSL as of Insider 17063 and Spring Creators real soon now. If the drive isn't mounted with the 'metadata' feature, directories are going to take on the permissions of the mount regardless of your umask.

The other is the default umask, which is still 0000 (causing a 777 mkdir). That is #352 and is still open. There are work-arounds over there, the easiest being to set the umask in your .profile/.bashrc/.zshrc/.whateverrc.

clan@DESKTOP-63PQJNC:/etc$
clan@DESKTOP-63PQJNC:/etc$ clear
clan@DESKTOP-63PQJNC:/etc$ sudo mkdir docker
clan@DESKTOP-63PQJNC:/etc$ ls
clan@DESKTOP-63PQJNC:/etc$ sudo mkdir -m 777 docker
clan@DESKTOP-63PQJNC:/etc$ ls
clan@DESKTOP-63PQJNC:/etc$ ls -l
clan@DESKTOP-63PQJNC:/etc$

It cannot work

umask was 000 for me. Setting it to 022 in ~/ fixed things for me.