Installing Drupal: better documentation for file permissions

This basically depends on the operating system. The numeric permissions only make sense in the Unix world, and even there, you are making assumptions about the type of installation (server software, etc.). I'm not really sure we can do better then that here.

-1 to the idea of numeric permissions, since as #2 already mentioned, it is OS-dependent. The chorus of "what the blazes does 755 mean?" by the population of new Windows users will be deafening, no doubt. I also like that we're linking to the handbook, which provides a nice compromise.

Marking as Won't Fix, unless there's a compelling reason to change something here. If the handbook is somehow unclear on this, we should probably raise it as its own issue.

Although it helps to triage part of the issue (Windows users not knowing they can't chmod something), there are really two issues at play here: the first being if we're going to explain how to do it for one OS, we really should be doing it for all of them. Personally, I think the handbook is best suited toward this sort of thing, since users can then drill down to the specific issue they're having for their specific stack without bloating the inline help.

The other issue (as #2 mentioned before) is that with all of the possible server setups, saying "just chmod 755 $foo" isn't always the solution, either. Different environments may have their own nuances that we aren't accounting for here - though I haven't encountered any personally, http://drupal.org/node/50280 highlights some weird permissions issues that can arise when using SELinux, for example.

Given the amount of instruction we'll need to provide for introducing permissions while handling specific cases (and that the inline help is already a bit verbose), it seems that referring the user elsewhere for additional help is the best course. Of course, the docs there could probably stand to be tightened up a bit, but that's a whole other issue entirely.

I don't disagree with you (re: wanting/needing to improve D7UX), and appreciate the thoughtful response. However, given the intricacies of different server environments, we have to strike a compromise somewhere with respect to which help should be inline, and which help should be external (but directly referenced). Personally, I would argue that it isn't the job of the error message to provide environment-specific documentation, but to specify the problem and offer a solution - which it does as elegantly as it can. Catering to the 80% should not be at the expense of the 20%, or we *will* maintain that perception of complexity among those users - far better to guide everyone to the best of our ability.

Although my -1 remains unchanged for now, I am content to wait for some of the other UX folks to jump in, in hopes that we can reach some sort of consensus.

First up... this is about configuration rather than installation. It can happen multiple times whereas the installation of the software only happens once.

Now on with the show.

D6 currently requires you to do your own thing to create all prerequisite files and directories and then set protections so that it can access them for the site configuration. It then does a pretty poor job of reverting to a 'secure' configuration and telling you 'everything is now taken care of'.

So, on the one hand you want to leave it to the user to unlock everything - because it's too hard to do yourself - and on the other hand you want to try and lock it all up automagically and stuff it up because you don't take into account the environment - factor in SELinux for example.

I have no trouble accepting that coping with multiple operating system environments is very hard. On the other hand I don't see anything particuilarly hard in providing operating system specific scripts which will create and set protections on all required files and directories and, after configuration, lock them all down again. The user is then responsible for choosing the right script to run which, I would humbly suggest, is a little bit more reliable than trying to navigate through the mess of advice on this site.

Organisations that package Drupal and make configuration changes - such as Fedora - would be expected to provide their own scripts.

cheers

The user is then responsible for choosing the right script to run which, I would humbly suggest, is a little bit more reliable than trying to navigate through the mess of advice on this site.

In that case, we would be dependent not only upon end users to manage another configuration setting ("but $distro doesn't appear on that list, is it incompatible?!"), but distributions to find those settings to make our project work, while failing to address the very likely case of someone installing Drupal outside of a packaged environment with its own nuances. Don't get me wrong, I'm all for making life easier for the end user, but to do something even similar to what #8 suggests after we've already hit code freeze is a non-solution. New features like this would have to wait.

Fundamentally, the issue here is this: do we add additional OS-specific help into core to address file permissions during installation, or is what we have (indicating the error, offering a solution, and suggesting additional information) adequate? Or, alternatively, could the existing error message be better stated?

It seems clear at this point that there is no way forward with this.

IMHO, the proposal as it stands right now has too many holes in it. It doesn't account for environment-specific nuances, places too heavy a burden on package maintainers, nor does it solve a somewhat recursive problem: for a script to grant permissions, it must have the appropriate permissions, requiring the user to understand permissions enough to assign them in the first place. To the best of my understanding, I get the feeling that any attempts to get around this will result in poor security practice.

If we get something more solid down in the near future, slating it for D8 sounds awesome. Otherwise, in the absence of another solution, we should mark this Won't Fix (or, in retrospect, By Design may be a better fit here).

Jumped the gun a bit - leaving this open for comments/solutions for a while longer.

EDIT: My mistake, I thought I inadvertently set it to Won't Fix - didn't see that I was ninja'd! All the same, we should probably leave this open for at least another day or so to make sure we've reached consensus, no?

IMHO, the proposal as it stands right now has too many holes in it. It doesn't account for environment-specific nuances, places too heavy a burden on package maintainers, nor does it solve a somewhat recursive problem: for a script to grant permissions, it must have the appropriate permissions, requiring the user to understand permissions enough to assign them in the first place. To the best of my understanding, I get the feeling that any attempts to get around this will result in poor security practice.

Take a step back and have a look at what you are trying to do.

• Can the configuration script running in the context of the web server reliably change permissions on the required files and directories in order to complete all the required steps to configure this new Drupal instance. Well it's not running as root, or Administrator, or SYSTEM, or , so the answer would seem to be NO.
• Can the configuration script running in the context of the web server reliably change permissions on the required files and directories in order to fully secure the newly configured Drupal instance. Well it's not running as root, or Administrator, or SYSTEM, or , so the answer would seem to be NO.
• So can the configuration script ever reliably prepare and restore the required environment...again NO.

A code freeze seems like a good idea at this point! This is never going to work.

There are two distinct use cases involved here:

1. Configuration of the Default site after initial software installation.
2. Configuration of subsequent sites

The first case is an exception where the initial conditions can be specified by the package maintainer. Configuration of subsequent sites is more complex in that it involves the creation of directories, the copying files, and the adjustment of file ownership and protection before and after executing the configuration script. This assumes that the user preparing the environment has the necessary access and rights to perform these operations. This is an almost universal assumption where application installation and configuration are concerned.

This is what the web server context does not have.

So, as an alternative, what would be the effect of running the script in the context of the user who is supposed to perform the prerequisite setup tasks?

• Can the configuration script running in the context of the adminstrator reliably change permissions on the required files and directories in order to complete all the required steps to configure this new Drupal instance. The answer would seem to be YES.
• Can the configuration script running in the context of the web server reliably change permissions on the required files and directories in order to fully secure the newly configured Drupal instance. The answer would seem to be YES.
• So can the configuration script ever reliably prepare the environment, perform the configuration, and restore the required environment. Well IT NOW HAS A CHANCE.

This is still a non-trivial task if a generic procedure is to be crafted but it would seem that this approach is not the dead-end the existing approach is.

cheers

A code freeze seems like a good idea at this point! This is never going to work.

I think you may have misunderstood me here - I apologize for any ambiguity on my part. I was referring to the fact that no additional features will be added to D7 at this point. That's not a decision we have the liberty of making, it's simply too late in the development cycle - the code freeze has already happened. Only bug fixes should be addressed at this point, and new features should be queued up for D8 instead.

So, as an alternative, what would be the effect of running the script in the context of the user who is supposed to perform the prerequisite setup tasks?

* Can the configuration script running in the context of the adminstrator reliably change permissions on the required files and directories in order to complete all the required steps to configure this new Drupal instance. The answer would seem to be YES.
* Can the configuration script running in the context of the web server reliably change permissions on the required files and directories in order to fully secure the newly configured Drupal instance. The answer would seem to be YES.
* So can the configuration script ever reliably prepare the environment, perform the configuration, and restore the required environment. Well IT NOW HAS A CHANCE.

While the spirit of the solution is definitely there, unfortunately we're now increasing the attack surface of Drupal by giving a pre-packaged means of programmatically changing permissions around at the user level. From a security standpoint, we have to operate under the assumption that the user will forget to remove that script. That, and we're only partially addressing the issue for users who happen to run packaged installs, leaving the greater proportion of users exactly where they (we?) started with this issue in the first place.

I'm confident enough at this point to agree that this is addressed as well as it feasibly can be for D7 (given that we can't go about adding new features at the last minute), but I wouldn't mind seeing an issue opened against D8 to discuss how we can handle file permissions better for the next major release. :]

I made a cut and-paste mistake in my original extended comment...

• Can the configuration script running in the context of the web server reliably change permissions on the required files and directories in order to fully secure the newly configured Drupal instance. The answer would seem to be YES.

Should have read:

• Can the configuration script running in the context of the administrator reliably change permissions on the required files and directories in order to fully secure the newly configured Drupal instance. The answer would seem to be YES.

I am suggesting that the configuration task is taken right out of Drupal and made a stand-alone administration activity. It cannot be invoked via the browser interface. Since, with the exception of the Default site, some form of command line access is required to setup the environment prior to running the config process - create directories, copy files - then this access can also be used to run the configuration script. The attack surface is not increased since (a) the web server context does not have sufficient access to perform the required actions, and (b) the installation can protect the scripts from the server context in a variety of ways. If you can run the scripts and do any damage then you own the server anyway. If anything the attack surface has shrunk.

In terms of the code freeze...I was being a bit facetious, sorry. My feeling is that the current direction is flawed and that further work is not going to achieve much. A process running in the context of the web server is not going to have the privileges/rights/whatever to perform all the activities required to configure a site.

In terms of #15...yes, if you can get turn-key site configuration to work then you will be really cooking...but this must include full support for multi-site configurations, shared database tables and getting Clean URLs working without any further user intervention. I think you are only scratching the surface at present.

cheers

I think the last few comments here are not too closely related to the original issue... see #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) instead, which (the Drupal 8 version of it at least) would potentially allow Drupal to handle many of these file permission changes for the user.

I suggest we keep this issue about documentation. I would agree that the original proposal is "won't fix" since:

1. Many people don't use Unix servers.
2. Many people who do don't use the command line (especially the people who would most need help with this) - they might be using an FTP program where they just check a box to make something writable, not run any kind of chmod command.
3. Which numerical permissions to recommend varies from server to server
4. Simply saying something like "please give permission 752 for this directory" is still going to leave many people confused unless they already have a pretty good idea of what they are doing.

However, I think we should leave this open in case there is some other textual improvement that can be made to make things a bit more clear before giving the link to the online handbook - however, I can't really think of anything at the moment.

Isn't there a simple test for whether you're running under Unix, and provide numeric write permissions accordingly?

Otherwise, a more comprehensive page on write permissions (one click away), that details the permissions for each operating system. Let's not withhold the information for novices, if we know it.

A small improvement that could probably still be made in D7 would be to use posix_getuid() and posix_getpwuid() to at least find out what user needs to be able to write to the given directory. Something like:

function drupal_current_system_user_name() {
  if (function_exists('posix_getuid')) {
    $system_user = posix_getpwuid(posix_getuid());
    return $system_user['name'];
  }
  return '';
}

...

if ($system_user_name = drupal_current_system_user_name()) {
  $message = t('Drupal requires %directory to be writable by %user.', array('%directory' => $directory, '%user' => $system_user_name));
}
else {
  $message = t('Drupal requires %directory to be writable by the web server.', array('%directory' => $directory));
}

This would give a bit more help to the 90% of people that install Drupal on *nix.

@ dalin - where is your proof that 90% of people install on *nix? People say things like this but Drupal has been able to be installed on IIS for years and as a result it has been a popular CMS to deploy on Windows servers.

We should be helping newbies install Drupal. This means we tell them where there is an error, and suggest a solution. Ideally "Yes" should be in green, and No! should be in red. I would suggest all of the follow, which is clear and informative. eg.

Checking file and directory settings:

If an entry in the table shows "No!", then you must correct the issue. Some solutions are shown below.

Solutions

• If a file or directory does not exist (shown as No! in the table), you must create it.
• If a file or directory is not writeable (shown as No! in the table), you must make it writeable.

Details

The solution depends on the server operating system used to host Drupal (usually Windows or Linux/Unix). To make a directory/file writable

• In Windows: right click on the directory/file, select Properties | Security, and set the Guest account to Read Allow. For more details click here
• Linux/Unix: To make a file writeable, you need to change its "permissions" to 753. For more details click here
• Others: Consult your operating system manual

@22 - I would suggest removing the (753). If you are going to put in extra information then it would go in the 'Solution Details' you propose. Due to the variety of configurations from hosting providers to self built servers and the few comments already on the Linux page, the actual needed permissions and steps to achieve them are not going to be consistent on all distro's.

@sepeck There is no way to know the exact percentage of *nix vs. windoze for Drupal installs. But my feeling, based purely on subjective things like how many forum posts I've seen about one vs. the other, the Drupal community is heavily weighted to the *nix side.

Regardless it doesn't matter. The fact that for a good-percentage of our users, perhaps a very high percentage, we can be able to tell them what user needs to have write access, and that we can't say 753, or 757 or the like, this little bit of info can help a lot.

I'm also a fan of the table. It's a lot more clear. However this is really looking like a D8 solution.

@dalin, if you are going to make up numbers for your justifications then yes it does matter. Especially as it causes these little disputes in the issue queue when people do make things up. Drupal.org has often proven less then welcoming to people running IIS and as a result we as a community have failed a large share of our potential users with that hostile attitude.

As to whether or not there is majority platform used for Drupal (which we now no longer know) the requirements page clearly states that Drupal will work on Apache and IIS.

Drupal has been deployed successfully on both Apache and IIS...... Drupal is being developed to be web server independent, but we have limited or no reports of successful use on web servers not listed here.

Please note that Apache and IIS are listed and tested by members of the community.

The exact combination that arrives at 'write access' and what account that needs to be granted depend on a lot of things far out side the control of Drupal itself. I like the diagram in #22, I do not like the inclusion of the number to which I provided my above feedback(#23). I would add that I think adding local help pages with this information would be more beneficial then linking back here but if we do link back here then we need aliased doc pages.

Oh, it's spelled Windows with an 's', not a 'ze'.

Something like the table in #22 sounds like a fantastic idea and a usability win for non-technical users (like me). However, it strikes me as something that could be done on the status report page rather than at install time. That way we can check to see if permissions are set correctly and not bother the admin if they are. If they're not, we could simply provide a warning to check the status report like we do for other issues.

#22 sounds like a good approach, and will remove the "d'oh, I need to create the directory // refresh // d'oh, I need to make it writable // refresh // oh, good" nightmare.

I agree with #25: both for Windows and Linux, the details on how to make the "writable" happen depends on the particular setup. Don't mention details, and just link to the handbook.

Patches welcome.

From a semi-newbie's perspective, yes, we need a superior way of addressing required directories and permissions to avert D7 installation and runtime errors.

Already, though, I can see issues with #22.

For instance, what if I'm configuring a multisite with both the primary and the subsite directories named after their domain/TLD and existing independently off sites/? In this case, having sites/default/settings.php may create confusion (instead, I have a separate settings.php in each of the "domain name" directories and only a single copy of default.settings.php within sites/default/).

The subtleties add up fast when configuring even a relatively simple, two-site multisite. Because even then you have more directories to worry about setting permissions on.

My goal would be to see a more robust "installation wizard" in D8 that would account for factors like these, plus a means to migrate an existing domain name (on another "live" site) to a from-scratch Drupal site--if necessary, using a temporary domain on a staging site until that's ready to assume the original domain. This was my real-world scenario and it's been a bear to say the least, getting the impression that D7's installation always assumes a fresh domain name on a brand-new site that is never a multisite.

Configuration: IIS on XP Pro, PHP 5.3.1, MySql 5.1.41

Although install script did not give any errors at "Verify requirements" step, only the sites/default/files folder created.
But those are not created:
sites/default/private/files, sites/default/private/temp (or is it sites/default/temp? thread description vs. #1) etc.
settings.php file created and seemes fine too.

After the setup I get "Page not found / The requested page could not be found." (see install-08.jpg)

Defined and commented out "$base_url = 'http://...';" line in sites\default\settings.php as recommended, nothing changed.

I created all the recommended folders manually (although a complete list is not given neither here nor in documentation), grant write permissions to all, nothing changed.

Can create menus and content but could not see them. Can list modules but cannot install.
Should be something related with DRUPAL_ROOT variable.

I will not get into "20-80% discussion" or "let those MS users curse their OS" approach (though I do every single day). No excuse is relevant to deny "Drupal is being developed to be web server independent" declaration.

Drupal says that a certain folder does exist but that it (Drupal) cannot make it writable. Is there a way to grant Drupal the privilege to make files/folders writable?

Sahin, Geir19, welcome! The issue here is for how to update the documentation for file permissions, not for specific support requests related to them. I suggest you have a look at http://drupal.org/node/73179 on how to do that, specifically the section on "Support Requests." Chances are, you'll get a lot more in the way of responses.

Back on topic, #28 raises some interesting points regarding multisite. Without getting into revisiting the entire installer UX (which is entirely valid, but beyond the scope of this issue), wouldn't it be possible to just dynamically extend the table in #22 to account for and include multisite files and directories?

Sahin, Geir19, welcome! The issue here is for how to update the documentation for file permissions, not for specific support requests related to them. I suggest you have a look at http://drupal.org/node/73179 on how to do that, specifically the section on "Support Requests." Chances are, you'll get a lot more in the way of responses.

Back on topic, #28 raises some interesting points regarding multisite. Without getting into revisiting the entire installer UX (which is entirely valid, but beyond the scope of this issue), wouldn't it be possible to just dynamically extend the table in #22 to account for and include multisite files and directories?

Also, as others have said, this is clearly 8.x territory we're in. :]

And the Drupal site configuration script is going to CREATE these multisite files and directories?

I go back to my comments in #14 and #17. If you are configuring outside of /default then you have to create files and directories from scratch and this needs access over and above that available in the web server context (one would hope!). Distributions such as Drupal for Fedora manage to place files in a variety of areas in the file system, Drupal still works fine. Placing a configuration script outside of the reach of the web server should not be a problem, I use one to create directories and set permissions (including SElinux permissions) for multisite installations as a matter of course.

If the concept of an external script is followed further then wierdness such as this (http://drupal.org/node/791004) would be a thing of the past.

cheers

Per #33.

#34 - I'm not sure I follow. If you're referring to a configuration script as a solution, as #18 mentioned, the current issue is just about the documentation. For the sake of keeping things tidy here, we could always create a new issue to discuss.

I like the approach of #22, and while keeping in mind that we'll have to extend it for multisite setups, there are a few tweaks we could make:

* "Click here" is a UX antipattern. Links should be clearly labeled, and in their appropriate context wherever possible.
* Not sure the exclamation point is necessary (emotional response: "Why is Drupal yelling at me?"), though I agree with the use of color
* Redundancies such as "(shown as No! in the table)" and tangents like "(usually Windows or Linux/Unix)" could probably be removed to improve clarity
* As per #23, we should probably avoid anything OS/distro-specific until we start referring to handbooks
* Using passive voice for changes that have to be made tends to place the emphasis on informing the user about what needs to change, rather than implying fault for some misconfiguration
* Solutions should probably be shown conditionally, only if there's an issue
* Solutions and details could probably be merged and reworded for clarity

So with the table in #22, maybe something like:

If a file or directory above does not exist, it must be created before continuing.

If a file or directory above is not writable, it must be made writable by following the instructions for the operating system used to host Drupal (Windows, Linux/Mac/Unix).

Thoughts?

One thing that makes things a bit more complicated is that the file has to specifically be writable by the web-server (possibly, but not likely to be the same user that you browse the files with) . We can also let them know which user is running the webserver (by looking at the $_SERVER variable). Also one of the challenges is that we don't want to give advice that would cause security issues (i.e. change the permissions to 777). Though simply being on shared hosting is a security issue since any other website on the machine can write to your sites/default/files directory (not sure if we need/should be stating this either).

#37 - All of these issues should be addressed by the handbook pages linked to in my (and #22's) example above. :]

Two points:

• The multisite scenario is the only use case that covers all the bases. The distribution you installed will provide minimal framework to build on.
• The fact that in the execution context of the web server something looks wrong - for example, file not found - does not mean that the file does not exist. For example, incorrect directory/folder permission could lead to the same result.

So if you want to fix this in the documentation:

1. Take it from the top - full multisite use case
2. Describe in generic terms all the potential scenarios that can lead to a particular error condition
3. Create platform specific handbooks that may contain example scripts.

You also need to consider the post configuration position where the conditions that need to be satisfied to perform the configuration are no longer sensible. Do you really want settings.php to still be writeable?

Two points:

The multisite scenario is the only use case that covers all the bases. The distribution you installed will provide minimal framework to build on.
The fact that in the execution context of the web server something looks wrong - for example, file not found - does not mean that the file does not exist. For example, incorrect directory/folder permission could lead to the same result.

Agree with the first point, though a file not existing and not having permissions to access a file that does exist are in fact entirely different and distinguishable from each other. There's no need to make the user guess if we can tell the difference ourselves.

So if you want to fix this in the documentation:

Take it from the top - full multisite use case
Describe in generic terms all the potential scenarios that can lead to a particular error condition
Create platform specific handbooks that may contain example scripts.

We've already addressed the need for the first point here. The second and third are already addressed by linking to the handbook pages at the end of the examples I mentioned.

You also need to consider the post configuration position where the conditions that need to be satisfied to perform the configuration are no longer sensible. Do you really want settings.php to still be writeable?

Drupal already informs the user post-installation if your file permissions are off.

EDIT: Realizing that the fact that we're referencing the installation guide could be made more explicit. Perhaps instead, something like this?

If a file or directory above does not exist, it must be created before continuing.

If a file or directory above is not writable, it must be made writable before continuing. Detailed instructions for Windows, Mac, Linux and UNIX environments can be found in the online installation guide.

There's no need to make the user guess if we can tell the difference ourselves.

Totally agree. Just don't under estimate the challenges involved in determining the root cause of an access issue when you are running in the context of a (hopefully) non-privileged user. The fact that the user may be able to operate in a different context - and hence have a different view of the world - can also be a source of confusion. Here are a few scenarios:

• File does not exist
• File exists but folder permissions do not allow you to see it
• File exists but folder permissions in the path to the containing folder do not allow you to get to it
• File exists but you have absolutely no access to it (there is no way you can open it)
• File exists but you do not have the required access to it (i.e. you can open it in some modes)

If updating a file also requires creating a new copy of the file then there additional consideration at the containing folder level, i.e. you may need write access to that as well.

Drupal already informs the user post-installation if your file permissions are off.

And don't forget folder permissions as well, all of them, from the root of the file system down if you really want to get it right. It is possible to logically manipulate a file without having access to it if you can manipulate the directory structure.

Totally agree. Just don't under estimate the challenges involved in determining the root cause of an access issue when you are running in the context of a (hopefully) non-privileged user. The fact that the user may be able to operate in a different context - and hence have a different view of the world - can also be a source of confusion. Here are a few scenarios:

(snip)

For sure. It looks like those situations are already addressed in the handbook, though; if not, they should be.

And don't forget folder permissions as well, all of them, from the root of the file system down if you really want to get it right. It is possible to logically manipulate a file without having access to it if you can manipulate the directory structure.

Yep, we're already checking folder permissions within the Drupal instance. I'm not sure Drupal should be responsible for checking any further than where it is installed, however.

Any other suggestions for the content of what we'll be saying? If this looks good to everyone, I think we can start writing patches.

So can this still be addressed in D8? Would be a real shame if it had to get bumped again.

What can we agree on that would be a small step ahead on this issue?

I think we can do something like this by using the posix_*() functions (though not quite so verbose):

For installation to continue the file [path/file] needs to be writable by the web server. Your server is running a Unix-based operating system. The web server is running as the [user] user and belongs to the groups [group list]. The file is owned by the [user] user, and belongs to the group [group]. Since the file and user share a group, you can either make the file group-writable, or setup an ACL that would allow [user] to write to [file].

Or

For installation to continue the file [path/file] needs to be writable by the webserver. Your webserver is running Windows. Please adjust permissions of the file so that the webserver can write to it.

There doesn't appear to be to be a Window's equivalent to the posix_*() functions.

@dalin any other thoughts about how to pull out that info?

I haven't used PHP's posix functions before.. We'd need to add in php-process though right? Or is that included in 5.4?
http://www.php.net/manual/en/function.posix-geteuid.php
http://www.php.net/manual/en/function.posix-getpgrp.php

I'm not sure if we could use getenv('APACHE_RUN_USER') to find what we need.... However we could at least send them to some help links.

if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
    // If the directory is not writable and cannot be made so.
    form_set_error($form_element['#parents'][0], $form_state, t('For installation to continue the directory %directory needs to be writable by the webserver. Your webserver is running Windows. Please adjust permissions of the file so that the webserver can write to it.', array('%directory' => $directory)));
} else {
    // If the directory is not writable and cannot be made so.
    form_set_error($form_element['#parents'][0], $form_state, t('For installation to continue the directory %directory needs to be writable by the web server. Your server is running a Unix-based operating system. ', array('%directory' => $directory)));
}

We'd need to add in php-process though right? Or is that included in 5.4?

Not sure what you mean.

I was thinking something along the lines of this (we shouldn't be trying to detect any specific OS):

function os_get_user_name($os_uid) {
  if (function_exists('posix_getpwuid')) {
    $process_user_info = posix_getpwuid($os_uid);
    if (!empty($process_user_info['name'])) {
      return $process_user_info['name'];
    }
  }
  return $os_uid;
}

function os_get_group_name($os_gid) {
  if (function_exists('posix_getpwuid')) {
    $process_group_info = posix_getgrgid($os_gid);
    if (!empty($process_group_info['name'])) {
      return $process_group_info['name'];
    }
  }
  return $os_gid;
}

function os_get_current_user() {
  if (function_exists('posix_getuid')) {
    return os_get_user_name(posix_getuid());
  }
  elseif (getenv('USERNAME')) {
    return getenv('USERNAME');
  }
}

function os_get_current_group() {
  if (function_exists('posix_getgid')) {
    return os_get_group_name(posix_getgid());
  }
  // Not sure if this is a real thing.
  elseif (getenv('GROUPNAME')) {
    return getenv('GROUPNAME');
  }
}

function file_get_user_name($file_path) {
  return os_get_user_name(fileowner($file_path));
}

function file_get_group_name($file_path) {
  return os_get_group_name(filegroup($file_path));
}

posix isn't installed in 5.4 by default yet. That's all I meant.

In #45 you had a Windows/Linux target messages. I was just thinking about that. We can just make it general and not include specific chmod/chown/chgrp calls to fix file permissions.

Here's a patch that works with the code you provided above. I think this was inline with what you were proposing. Feel free to revise it.

posix has been a part of PHP core since PHP4. But some *AMP packages go out of their way to remove it.

I did some more work on this to try and make the messaging in these three places (translations directory, files directory, settings file) more consistent.

Some follow-up questions/tasks:
- Need to add an is_readable() check for the files directory, just like the others.
- Might break out those long t() calls into separate parts like $server_permissions, $file_permissions, $more_help, and then assemble the appropriate bits when necessary.
- The following functions might be moved to Drupal\Component\Utility\FileSystem drupal_install_fix_file(), drupal_install_mkdir(), drupal_verify_install_file() as these are all generic. Then it wouldn't be so strange to use drupal_verify_install_file() in system_requirements().
- The files directory has install and runtime checks in system_requirements(), but settings.php has install checks in install_check_requirements() and runtime checks in system_requirements() with some code duplication.

• There is still a need for better documentation, i.e., an explanation of what setting the file permissions is meant to achieve, so automatically EOLing this isn't a good idea.
• When thinking about permissions, most installations may run apache+mod_php, which both run as the same user. This isn't true for instance in the nginx+php-fpm scenario.
• A murky area from my point of view is what happens on an "update" - clearly parts of the tree must be writable - all of them? by the php process?
• There are comments above about not using numbers for chmod. After the general explanation, a specific example, with numbers, would be good, so the rest of us know what you actually require and can translate to our own operating systems without needing to guess.

Case in point: I see on https://www.drupal.org/node/244924

That is, all of your files should be 'read only' for the Apache process, and owned with write permissions by a separate user.

I am not sure what "greg-user" is doing - manually unzipping modules in the directory he owns?
I just untarred file_permissions-7.x-1.0.tar.gz to try to find out what you think the setup should be.

• I don't see what most of the files should be set up to be
• sites/default, sites/default/files sites/default/private are treated specially, and chowned to apache_user:apache_user. What if mod_php is in fact php-fpm running as its own user?

Please could someone who understands what is meant to happen please update the documentation for us mere mortals?

Another case: when an update is available for a module, what permissions should modules' files have so that clicking on "update" works.