File Upload not working
Permalink
concrete 5.6.0.2 - single core - multi-instances-environment.
core installed in /usr/share/php/concrete5/5.6.0.2
all folders (all - except "files" & "config") moved to /usr/share/php/concrete5/
symlink /usr/share/php/concrete5/latest-stable -> ./5.6.0.2
var/www/instance1/ :
all folders symlinked to usr/share/php/concrete5... EXCEPT "config" for DB-connection to instance1's db and "files" obviously
purpose: instance2 is a copy of 1 with only different db-content, etc., etc.
that said, maybe it is of matter, maybe not. so far everything worked fine.
now, i try to upload a file and that doesn't work (*shown* Error: "Unable to copy file to storage directory. Please check permissions on your upload directory and ensure they can be written to by your web server." - i doubt it to be fooling) i experimented with chown & chmod on the files folder.
strangely, some items (e.g. cache) are created under apache's www-data:www-data others (earlier) are under root:root (silence theme's cached images)... when i chown www-data:www-data the whole files-directory then site is not shown correctly - even with chmod 777 (wtf???).
with root:root and chmod 777 on the files-directory, fresh directories like 2913 (apparently image dirs as suggest the other dirs of this format) are created under www-data:www-data when the error occurs, that uploadrights are not granted...
I don't get it. More rights are not possible (777) and I tried both www-data and root... And why the heck is my theme blown up, if I change its caching directory to chown www-data:www-data and 777?
I recently manipulated server to increase security (httpd and apache modules). The file i'm trying to upload is an image with ca. 25 kb. -> very high stress/kb-ratio. that's not fair!
Anyhow: Anyone any hint?
core installed in /usr/share/php/concrete5/5.6.0.2
all folders (all - except "files" & "config") moved to /usr/share/php/concrete5/
symlink /usr/share/php/concrete5/latest-stable -> ./5.6.0.2
var/www/instance1/ :
all folders symlinked to usr/share/php/concrete5... EXCEPT "config" for DB-connection to instance1's db and "files" obviously
purpose: instance2 is a copy of 1 with only different db-content, etc., etc.
that said, maybe it is of matter, maybe not. so far everything worked fine.
now, i try to upload a file and that doesn't work (*shown* Error: "Unable to copy file to storage directory. Please check permissions on your upload directory and ensure they can be written to by your web server." - i doubt it to be fooling) i experimented with chown & chmod on the files folder.
strangely, some items (e.g. cache) are created under apache's www-data:www-data others (earlier) are under root:root (silence theme's cached images)... when i chown www-data:www-data the whole files-directory then site is not shown correctly - even with chmod 777 (wtf???).
with root:root and chmod 777 on the files-directory, fresh directories like 2913 (apparently image dirs as suggest the other dirs of this format) are created under www-data:www-data when the error occurs, that uploadrights are not granted...
I don't get it. More rights are not possible (777) and I tried both www-data and root... And why the heck is my theme blown up, if I change its caching directory to chown www-data:www-data and 777?
I recently manipulated server to increase security (httpd and apache modules). The file i'm trying to upload is an image with ca. 25 kb. -> very high stress/kb-ratio. that's not fair!
Anyhow: Anyone any hint?
Fromhttp://php.net/manual/de/features.safe-mode.php...
Note that safe mode is largely useless. Most ISPs that offer Perl also offer other scripting languages (mostly Perl), and these other languages don't have the equivalent of PHP.
In other words, if PHP's safe mode won't allow vandals into your web presence, they will simply use Perl.
Also, safe mode prevents scripts from creating and using directories (because they will be owned by the WWW server, not by the user who uploaded the PHP script). So it's not only useless, it's also a hindrance.
The only realistic option is to bugger the Apache folks until they run all scripts as the user who's responsible for a given virtualhost or directory.
Note that safe mode is largely useless. Most ISPs that offer Perl also offer other scripting languages (mostly Perl), and these other languages don't have the equivalent of PHP.
In other words, if PHP's safe mode won't allow vandals into your web presence, they will simply use Perl.
Also, safe mode prevents scripts from creating and using directories (because they will be owned by the WWW server, not by the user who uploaded the PHP script). So it's not only useless, it's also a hindrance.
The only realistic option is to bugger the Apache folks until they run all scripts as the user who's responsible for a given virtualhost or directory.
switching off DEPRECATED safe mode in php.ini did the trick...
seems that I followed a deprecated server hardening tutorial.. ;)
seems that I followed a deprecated server hardening tutorial.. ;)
Warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 0/0 is not allowed to access /var/www/germering/files/cache/fdfbf4ed920dbd7088097693876fbb5f_f2.png owned by uid/gid 33/33 in /usr/share/php/concrete5/5.6.0.2/concrete/core/helpers/image.php on line 176 Warning: imagepng(): Invalid filename
-> Somehow there are 0/0s and 33/33s going arround?!?
vi /etc/passwd ->
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/bin/sh