Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A little background first: I'm doing some Drupal site-building on a Windows 7 machine. Drupal has an image module which, in short, allows for image caching. When you create an image style, the module creates a directory. For instance, if you create a style my_image_style it will automatically create a folder sites/default/files/img/styles/my_image_style/and/some/other/folders/beneath. However, the created directory has the owner:group Administrators:System with permission d--------+. Everything else, going all the way up to root is chrisrockwell:None. Apache (this is a WAMP5 setup) is also chrisrockwell:None.

The Drupal module needs to create files in this directory, but cannot because of the permissions issue.

So, in this set-up, how to I specify what user:group a created directory belongs to?

I'm not sure if it has an effect, but I do mostly everything within cygwin (moving around, opening, vim).

Please let me know if you need additional information, or if this is better suited in another site.

UPDATE: If I chmod 777 the entire site directory, the only folder I get permission denied on is the image_style folder that is created by Drupal's script.

share|improve this question
Note, d---------+ does not mean that there are no permissions; the + means that there is an access list associated with the directory that cannot be displayed as simple permissions. – Darth Android Jul 23 '13 at 16:25
@DarthAndroid I'm thinking it does have to do with Windows ACL's. Even if I chmod -R 777 the entire directory, running as Administrator, the permissions are still -rw-r--r--. I don't know much about ACL's, so I'm having troubleshooting issues – Chris Rockwell Jul 23 '13 at 18:14
I went so far as to give every user, every group, Full Control over this particular directory, to no avail. – Chris Rockwell Jul 23 '13 at 18:14
up vote 0 down vote accepted

Cygwin remarks

This is a workaround rather than an answer.

I've recently run into similar issues with Cygwin. The cause seems to be a misconfiguration in how windows users and groups are mapped to cygwin users and groups. Specifically, I've seen that the "Security" tab in the "file properties" dialog contains "Group or Username" entries such as OWNER and GROUP. I assume these are unsupported by windows.

It may be worth looking into the mkpasswd utility and reading up on windows ACLs to resolve this permanently. However, so far I've been able to get rid of all file permission errors by resetting the windows ACLs to defaults like so:

wraptor: ~/tmp/su/find-xargs
$ icacls.exe . /reset /t
processed file: .
processed file: .\.search-dirs
processed file: .\.test
processed file: .\dirz
processed file: .\foo
processed file: .\moo
processed file: .\sensors
processed file: .\.test\
processed file: .\dirz\
processed file: .\foo\
processed file: .\moo\
processed file: .\sensors\
Successfully processed 12 files; Failed processing 0 files

After this, it's sometimes necessary to traverse the hierarchy and reset the permission bits:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

After these steps, the files are correctly "owned" by windows-me or the Administrator user and native windows programs can read and write these files as usual.

Attempt at an answer

Apart from that, umask should be mentioned. It is set in a users' environment (or for a pocess in a program) and governs the permissions of subsequently created files and folders.

e.g (bash)

umask 0022

This will cause all files and folders to be created with 644 and 755 permissions.

e.g (python)

$ cat
import os
for _ in ('0022', '0002', '0077'):
        os.umask(int(_, 8))
        with open('moo.f-%s' % _, 'w') as f:

$ python; ll moo.f-*
-rw-rw-r-- 1 1K 2013-07-24 07:46 moo.f-0002
-rw-r--r-- 1 1K 2013-07-24 07:46 moo.f-0022
-rw------- 1 1K 2013-07-24 07:46 moo.f-0077

PHP has an "identical" umask function.

More info here: man 3p umask

share|improve this answer
I'll look into umask - thanks. Your work around has solved my current issue and allows me to get back to work on this module. I'll note that I had to run the .exe from cmd rather than cygwin in order for it to effect. Thanks much! – Chris Rockwell Jul 24 '13 at 14:42
Don't mention it :) If you figure our what's causing Cygwin to clobber windows permissions, I'd appreciate a comment. – Ярослав Рахматуллин Jul 24 '13 at 17:22

I've seen similar issues with other applications in Windows setting the group wrong when running as Administrator. I don't know how to fix the original directory creation issue, but you can reassign the owner and group for all the directories in cygwin using chown:

chown -R chrisrockwell:none my_image_style
share|improve this answer
Thanks, I had already chown'd the directory. Even though chrisrockwell:None is now the owner:group, the Drupal module still can not read/write. – Chris Rockwell Jul 23 '13 at 18:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .