I'm relatively new to web development, so please be patient.

I'm primarily an iPhone developer, but have recently done a site for someone else using shared hosting. I could write to files in PHP on that site fine, without having to think about permissions.

I'm in the process of deploying a web service for a new app I'm making, but it's not really going smoothly. The most important difference here is I'm using someone else's server, and just have FTP/DB access.

Basically, I have a load of PHP files which make up my CMS, like so:


Those scripts then either edit the database, or files. They can interact with the DB fine, however, my scripts cannot write to the filesystem. They might, for example, attempt to write to the following files:


This worked fine on my MAMP install (locally), but once deployed to the server, PHP spewed out errors everytime a write was attempted... something like this:

Could not open file "../data/img/someimage.png" for writing.

So I emailed the guy who's running the server, and he came back saying:

Does it work with public permission? (777)

And, it did - but I was very cautious with using public permissions, so disabled it straight away again. I emailed him saying "how can I make my PHP scripts write using standard user permissions", and he said:

Leave it as public, it'll be fine

I reckon it's an ip conflict somewhere in the domain resolution, but I'm not worried about it.

I then emailed him saying "surely this is insecure" or something along those lines, and he replied with the following:

the reality is that there are millions of website, including several that I manage that have 777 on various folders, it's just a way of life.

Could anyone give me some idea of a solution I could give him? Or what I can do to avoid having to use 777? I really don't like the idea of any folders on my site/service to be publicly writeable.

I would very much appreciate your advice as I know very little about web servers.

  • 12
    Run away from this guy and don't look back.
    – user9517
    Dec 18, 2011 at 18:59
  • Not really an option... see the comments on SvenW's answer... Dec 18, 2011 at 19:16

2 Answers 2


Let's break it down:

You need the user running the script to read, execute and write on the directory, so it should be:

7 = (r)ead,(w)rite,e(x)ecute

Other users belonging to the same group should be able to execute the php file within the directory, but not write to it (for obvious reasons); they don't necessarily need to read the PHP files. Therefore, we need to provide just execute permissions:

1 = e(x)ecute

Same for the public. In fact, that's all you need for external users who need to view php and static files:

1 = e(x)ecute

So the bare minimum should be:


I confirmed the above settings with my own configuration, so it should work; however, this is under the default web user. If you are uploading with a login other than www, the files and directories would probably be under a different user. In that case, the default web user may not be able to read or write the files that are owned by you. At that point, you probably need to add the default web user to your group (the sysadmin will have to do that) and then give read, write and execute permissions to users belonging to the group:


And that would probably work. Either that, or have the sysadmin change the user and group ownership of those files to the default web server user (but NOT THE PERMISSIONS!). If that still doesn't work, a sample output of the permissions (something like "ls -la within the directory") would help us troubleshoot this further.That said, as long as you only have to give execute permissions to the public (or "other"), you should be fine from a security standpoint.

  • 2
    Wish I could upvote twice.
    – Wesley
    Dec 19, 2011 at 2:49
  • The problem is really that the website should not write to files within it's own structure rather than the permissions themselves.
    – JamesRyan
    Dec 19, 2011 at 12:14
  • You're right. Depending on the data, you probably would want to write to a file outside of the public webroot.
    – Rilindo
    Dec 19, 2011 at 19:41
  • Here I'm writing to a /data folder - this folder contains PHP scripts which make up my JSON web service, and a bunch of images used for content passed down in the web service (in a /data/img folder) Dec 19, 2011 at 21:25
  • So the images needs to be public, then? That clarified things.
    – Rilindo
    Dec 19, 2011 at 21:29
Leave it as public, it'll be fine

I reckon it's an ip conflict somewhere in the domain resolution, 
but I'm not worried about it.

This guy is an idiot and this is complete nonsense. Access rights have nothing to do with IP addresess or domain resolution, he is just dropping words.

Given the quality of this "administrator", I would recommend to host your site elsewhere as it is very likely the site is administered very poorly and insecure. Just putting 777 permissions on something so that it works is a sure sign he doesn't understand a bit of what he is doing.

What access rights are really necessary is dependent on the way the system is used and configured and it is kind of hard to tell you something without knowing this.

  • thanks - my thought's exactly about the permissions - I don't really have an option to host it elsewhere as the company I'm developing for won't pay for it, and recommended me this guy and said that they'd get him to do it for free - from what I can tell I'm just running off one of his virtual servers. So how does it normally work, how can a PHP script run as a "user" and therefore be able to write to anything on the site? Dec 18, 2011 at 19:03
  • Well, I would inform them about what they get "for free". I have not much experience with any shared hosting, so I can't comment on that. My sites all run Debian web servers and folders that need to be writable will be owned by www-data with 700 permissions, but this is likely not going to work in your case.
    – Sven
    Dec 18, 2011 at 19:09
  • I think they're paying him for their main site as well so that's why - if it's any help at the bottom of any server error page it says this Apache/2.2.9 (Debian) PHP/5.2.6-1 Dec 18, 2011 at 19:14
  • also this is vps not shared Dec 18, 2011 at 19:45
  • 2
    Well, I try to figure out which what permissions and ownerships your files might be transferred to the server. If it is a user which is not at least a member of the www-data group, you either need to change users/groups after the transfer or indeed use 777 permissions. But this is pointless, we can't help you this way.
    – Sven
    Dec 18, 2011 at 19:59

You must log in to answer this question.

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