Folder Permissions

I have seen a lot of posts about this topic, but none could help me further...
Like many others in this forum, I cannot set the folder permissions according to the installation guide.

As said on http://docs.opencart.com/display/openca ... +practices we should set the config files to 644 or 444. But if i do that I get the Permission denied error because the config file cannot be included.

I have experimented a lot and found out that I need to assign public write permissions to the config files. This seems quite unsafe to me.

So what's the problem? On the one hand I don't think that ANY user should have write permission on the config. Read and Execute should be enough! On the other hand is the user under which I upload the files (username = myuser) not the same user that is running the apache process (username = apache). I figured if I put them into the same user group, the group permissions would be sufficient.

The following output shows that the apache user is now member of the same group as the user who made the upload. Well, in theory this looks nice but in practice I get the same errors...

Enough threads in this forum propose to set it to 777 - Let's stop this nonsense. It's crazily unsafe to do this.


If anyone (with some linux experience) could help me, I would be very thankful.

Directories 755, files 644, use free FileZilla client starting in root to recurse twice, once dirs 755, then files 644. If your host does not allow 755 for some reason, consider changing hosts. You are already aware of what each 7 and position means for owner/root, group/system, and world/anybody. In .htaccess prevent viewing dir content, and prevent viewing particular file extensions (those are in .htaccess.txt, rename .htaccess, if you haven't already). The two config.php will be okay as 644 with view prohibited.

Pay strict attention if you (re)set 755/644 and they change back to 777, let alone while you are watching. If that happens you already have a problem, and in that event you may find "public" .dirname/ (dotted) directories with bad things inside them, along with executable bad things there as well as in plain sight bearing weird or just quaintly different names.php which can be addressed by browsing and executed very simply via http (at that juncture complete havoc or invasion can be executed in connections shorter than two seconds).

Thank you for your answer!

If your host does not allow 755 for some reason, consider changing hosts.

I would rather want to know how to configure my (dedicated) host so it will accept 755.

If your dedicated server is on a host that allows you to get down below public_html (or equivalent), and to get down to full root (/), then you can execute commands via scp utilities or putty.exe, and if you can moreover get down all the way to absolute root (/) below even Linux then you can reach and hand edit by eye the configurations, either on the command line or via transfer/edit/transfer. Which will determine whether you can do this or must ask support to do it for you. Let's assume you can get down to either full or absolute root.

Ascertain your distribution of Linux (Debian, Ubuntu, Red Hat, etc.), and for that check the publisher's own URL plus such places as stackoverflow and various essential Linux sites for "configure Linux" then add "permissions" and look for the configuration files and Linux commands that suit your distribution and your need. You're looking for commands and files that tinker with the os itself, whether editing files or forcing settings. You can reach the generic basics easily enough, but the distribution actually will have specific dos/don'ts and cans/can'ts (loading software, for example is not as simple as on win but is straightforward, yet alternate commands for it may not work equally well or at all). if you are not yet accustomed to using an scp console or putty.exe, then take time to practice with it doing simple commands so that you have the feel of it before an oops or an ulp might be, um, dreadful.

If you cannot get down there, then your dedicated server is supplied, and you're not shared but you're shared anyway at a different level, above Linux itself. Then support will be your only way out.

On certain cloud hosts you essentially set up the entire nine yards, enchilada, and shebang all by yourself, combined Linux/Apache/php/smtp/pop3/imap/mysql all together from scratch, with complete freedom to make your setup work or to self-destruct. If you had that luxury you'd already have done the permissions. Those can be more fun or less fun than might seem the case (you're on your own, with few "house rules" and no effective support for any "little" stuff).