After duplicating a site that I had live on a dev server, no images are loading & I can’t seem to access the panel / etc. I’m pretty sure I have permissions correct, but something else seems to be exploding.
Any ideas?
.htaccess missing? Rewriting not enabled?
What is console output on panel login?
Kirby \ Exception \ Exception (error.session.filestore.dirNotWritable)
The session storage directory “/var/www/html/my.domain/public_html/site/sessions” is not writable
I thought it might be .htaccess @texnixe - as it was when I originally uploaded this action, but it feels like something else.
I’m getting 500 errors on all my images too. They exist in the folder the pages are trying to load them from - I’ve tried everything I can think of to solve for permissions.
Here’s what I did - running a Ubuntu 18.04 server - I had a virtual host setup - domain.conf and all that. I duplicated it & added a new domain to the server, copied all the files, went through all the normal steps, and now -both- domains won’t load images or allow access to the panel.
If I try to access an image through a direct URL, I get a “Permission denied” Kirby error page.
Ok - I think I did something wrong with chown - looks like all chmod settings are only applied for the root user. I’m not sure what the appropriate method to use for “global” users is.
That seems to be a permission error, check your folder/file settings, including subfolders (should be 755/644).
Make sure that all folders/files are owned by the Apache user as well.
1 Like
Yep! I had locked it out. Thank you @texnixe - I’m happy to report that my site appears to be alive and kicking! https://vega.studio
1 Like
Hi @texnixe, where do I find these file/folder settings?
@_jack That’s a OS setting, nothing Kirby related. Are you on Windows or on Linux/Mac?
I’m on Mac. Having the same error when I deploy my site, the site works but the panel gives this error: The session storage directory “/home/public/site/sessions” is not writable.
I found and updated the permissions of the folders on the server to 755, and the files to 644 using cyberduck. Though still getting the same error.
Then check file ownership. The files must be owned by the Apache user. On a remote server, that is usually www-data.