"Folders not writable," but all set to 755

Kirby 2 Solved ✅
1

We just recently moved to a different server so I’m guessing that might be a factor.

When I try to log into the panel, I get redirected to /panel/install with the following errors:

  1. You are only allowed to run the panel installer from the same computer that is the server or by setting the option panel.install to true in your /site/config/config.php
  2. /site/accounts is not writable
  3. The thumbs folder must be writable.
  4. The content folder and all contained files and folders must be writable.

For Issues 2-4, all of those folders are set to 755. Isn’t that correct?

And I don’t understand Issue #1 at all, since I’ve been trying to access /panel.

Any ideas?

2

Are there any user accounts in the /site/accounts folder?

755 is correct.

3

Yeah there are.

Both are set to 644.

.logins is currently set to 666

4

Not only the permissions (chmod) need to be correct, but also the owner of the files/directory (chown). Which hosting provider are you using?

1 Like
5

My client is using a VPS on Servint (which is running cPanel)

6

Then you should make sure that all files are owned by the cPanel user and group.

2 Likes
7

I brought up what you said to my server guys since I don’t know anything about chown. Here’s what he said:

Looking into this further, the permission issue you’re encountering is likely due to your PHP handler, DSO. DSO is optimized for speed and performance, and one of the ways it does this is by running all of its PHP processes as the default user “nobody”. This results in permission problems for CMSs like WordPress, which appears to be installed in /home/tsz/public_html/, as the folders within the account’s web directory are owned by the account user, and “nobody” is unable to write to them.

The way to get around this, without setting a very insecure/open “777” permission structure, is to change/modify your PHP handler to instead run its processes as the account owner rather than nobody. There is a module for DSO called mod_ruid2 that will allow you to do this, while still maintaining the low resource overhead characteristic of DSO. suPHP is the other PHP handler popular with WordPress, offering more in the way of individual account customization than DSO, though it cannot benefit from opcode caching, and uses significantly more CPU.

We went with mod_ruid2 and now I’m able to log in and edit files just fine in our Kirby Panel.

Thanks for your help!