How to Set Up "sites/default/files" Permissions Properly on Windows

jayhawkfan75's picture

Thanks for any help. I thought this would be the perfect place to ask my question.

My setup: Drupal 7.15 / IIS 7.5 / PHP5.3 / SQL Server 2008

I started receiving these crazy "Permission denied in drupal_unlink()" errors after an update from 7.13 to 7.14 (and then 7.15). At first, I focused on the permissions for the tmp directory. But after getting some assistance from Drupal's issue queue, I was able to pinpoint the problem as being related to the "sites/default/files" directory.

This is because each time I updated Drupal, I'd get an error about how the "files" directory was not writable. So this is what I tried:

  1. I logged directly onto the server (IIS 7.5) using IIS Manager 7

  2. Under the "sites/default/files" directory, I changed the permissions for the IIS_IUsrs account to "Full Control". I still saw the errors.

  3. Under the same "sites/default/files" directory, I changed the permissions for the server's all users (SERVERNAME\Users) account to "Full Control". The errors went away.
    Please Note: This is an internal server, so I wasn't worried about hacking when I tested this out.

I was happy to see the errors finally disappear, but allowing write/execute permissions for all users on that server is obviously not what I want to do. I hate to assume, but I'm assuming that this isn't how Drupal intended it to be set up on Windows. Does anyone know how I should approach and/or solve this security/permissions issue? I'd really appreciate your help.

In the meantime, I'll keep looking around for a solution.


Check the Application Pool Settings

jrsinclair's picture

In more recent versions of IIS, the default configuration is for the site's application pool to create a new user with the same name as the application pool. If you're allowing anonymous access to the site, then allowing write permissions for this user should do the trick.

Things get more complicated if you're using some other form of authentication (like Windows/NTLM auth). In this case, by default IIS passes through the identity of whoever is accessing the site, and your permissions get a whole lot more complicated.

I hope this helps. By far the most frustrating thing about running Drupal on Windows is trying to get file permissions right because the Windows file permissions system is really complicated.

Hhmmm. This is interesting

jayhawkfan75's picture

Hhmmm. This is interesting and frustrating at the same time.

This is an intranet site, and there will be some users who can access the site anonymously because they're a department outside of our firewall.

But anyone adding files to the site will have to be authenticated. I planned on using the LDAP module to pull all Active Directory users into Drupal accounts, and then applying permissions based on pre-set roles that match their security groups. This part has definitely been the most difficult part of using Drupal on Windows for me.

If I set it up this way, can't I still use your application pool user name suggestion since the user's permissions will be set within Drupal? Does my plan sound doable (or even logical), or is there an easier way to combine AD users with Drupal?

I really appreciate your help!

The only way to know is to test

jrsinclair's picture

Your plan sounds feasible, but really the only way to know if it will work is to test it out. But I will say that I've just set up a very similar kind of project (though without the external login). We ended up setting fairly loose permissions on the sites/default/files directory (judging the risk to be low, given it's an internal application) and locking everything else down fairly tight.

Windows & Drupal Don't Play Nice

tomcat.javanet's picture

I have had a ton of issues with my site crashing after any updates in Drupal, going to look to go to a Linux box as to many weird issues with permissions in IIS7.5 to deal with and have had my development site crashed more than once with /sites/default/settings.php and .httaccess getting locked up so hard that I can't reset permissions, edit, rename move or delete. When I FTP a copy to local machine it can be edited and deleted, but then can't upload it back to live site. Why do folks want to use Windows to host a Linux/Unix based application in the first place?

You may be right

jrsinclair's picture

@tomcat.javanet, you're absolutely right - getting Drupal and windows to play nice can be a real pain. But, if you have to use Windows for some reason, then using Drupal on Windows is still better than SharePoint.

mgifford's picture

I'd really like to see a clean way to do this that can get migrated into the Drupal handbook - or

I found this, which was interesting.

It suggested using icacls you can grant access to Drupal’s settings.php & the files directory. By setting permissions using something like:
icacls settings.php /grant BUILTIN\IIS_IUSRS:(W)
icacls files /grant BUILTIN\IIS_IUSRS:(W)

That doesn't seem to quite work for me. I'm not sure what's different between the IURS & the IIS_IUSRS user.

I tried to leverage the GUI using something like -

Seems like there's a similar issue with SugarCRM:

Maybe this is related to the UAC User Account Control:

Oh ya, there are references from Alessandro's videos here

Other references to permissions in this group -

@alexpilotti recommended:
icacls D:/sites/WBSMBS/sites/default /grant IIS_IUSRS:(OI)(CI)(RX,W)

I'm still looking for answers though.

In newer versions of IIS, the

panmanphil's picture

In newer versions of IIS, the "user" the server runs under is no longer the IUSR account most older posts are talking about. In most cases the app pool defines the user and uses a mechanism call Application Pool Identity. It is kind of pseudo user, but can be used to set permissions.

basically the user to use is going to be IIS APPPOOL{your app pool name}

Here is a link to an article with an icals command showing this