System healthcheck shows setup/server setup of this OXID eShop might be broken

Hello again,

Files/folders access rights is showing up as RED indicating there is something that needs repairing/adjusting.

I followed the recommendations which led me to the “Files & Folder Permission Setup”.

I have changed permissions on the top 4 lines but do not understand what or where to make changes on the 5th line:

Those must be writeable all the time:
• /out/pictures/ (recurse into subdirectories)
• /out/media/ (recurse into subdirectories)
• /out/<sTheme from config.inc.php>/src/ (recurse into subdirectories) (/out/basic[azure]/src/ during setup)
• /log/ (recurse into subdirectories)
• [B]<sCompileDir from config.inc.php> (recurse into subdirectories) (/tmp/ during setup) [/B]

I suspect I will have issues with the last 2 changes as well. where do I find:

• /config.inc.php
• /.htaccess
and
• /export

Thanks for your help in advance. I have had a good look through the previous threads for help however it appears that the help keeps pointing to the Files & Permission Setup notes but doesn’t offer detailed destructions on how to get the FIX done.

Thanks

Don_in_OZ

CompileDir is normally /tmp-dir, directly at shop-rootlevel (if you did not specify something else in config.inc.php)

config.inc.php - .htaccess and /export-dir are located as well at shop-rootlevel

You can change those permissions via “chmod” or by right-clicking those files/folders for example in Filezilla -> Permissions

The alias you offered in line 1 was helpful and that is now squared away.

I am still having difficulty locating the other files and they do not appear to be in the root folder. I have attached an image of my root folder. Maybe they also have alternative names?

Thanks

Don_in_OZ

line 10 is /export - line 19 is config

Do you use a Mac? Maybe files with a dot in first place are hidden? Perhaps you even did not transfer the .htaccess then?

No I am proud to say I am not a MAC fan… plain old PC for me.

To my knowledge I fully transferred the full file as it was available to download about 2 weeks ago. Does this make it impossible to fix? or can I add the missing files now?

check for the .htaccess in the download from oxid and transfer it - maybe you need to adjust “RewriteBase” if your shop is not at rootlevel on your webserver

Strangely, .htaccess was there as I found out when I went to upload it to the root directory as it asked if I wanted to re-write it. This got me thinking that cPanel was perhaps not the best way to make changes on the run, so I opened up Core FTP Pro and it was immediately visible.
Core also had the recursive subdirectory option which cPanel didn’t have.

So now I have re-looked over all the recommended settings and made sure they were all 777 but still no getting away from the error message that points me to System health. How do I get past the bright red message:
System healthcheck shows setup/server setup of this OXID eShop might be broken. Probably this OXID eShop behaves strange in some cases. Please fix this as soon as possible. Support for fixing find in [COLOR=“Black”]system healthcheck.
Due to security reasons put your config.inc.php file to read-only mode![/COLOR]?

Don_in_OZ

set the config.inc.php to 644 or 444 and check the system health again

I wish your suggestion was the answer I needed but I still have the red message (no change).
To be sure I deleted all the files in the /public_html/tmp/ file

when i changed the /public_html/config.inc.php file to 644 firstly and then 444 lastly, I used the recurse sub-directories option which I presume was correct…

Can you think of what else might be ailing the setup?

Howw is the system health check? Any yellow / red marks? Any suggestions provided from the check?

[QUOTE=Hebsacker;63557]Howw is the system health check? Any yellow / red marks? Any suggestions provided from the check?[/QUOTE]

No Ray - nothing additional.

the start of the Admin page reads:

System healthcheck shows setup/server setup of this OXID eShop might be broken. Probably this OXID eShop behaves strange in some cases. Please fix this as soon as possible. Support for fixing find in [COLOR=“Black”]system healthcheck.
Due to security reasons put your config.inc.php file to read-only mode![/COLOR]

and then clicking onto “system health check” reveals all sectors green or okay with the exception of:
[B]access rights[/B]

Don_in_OZ

For clarification… image attached

Don_in_OZ aka NHWS

if it is not the chmod-setting of the config file (obviously not when set to 444), then I suggest to doublecheck the recommended settings here: http://wiki.oxidforge.org/Installation#Files_.26_Folder_Permission_Setup

check all of them with the ftp-client and set them again with “recurse into subdirectories, all files and folders”

I have done the doublecheck again and the only question I have might be the interpretation of:

/out/<sTheme from config.inc.php>/src/ (recurse into subdirectories) (/out/basic[azure]/src/ during setup)

I understand this to mean (<sTheme from config.inc.php>/) in my case Azure therefore:
/out/azure/src and then right click properties - 777 - recurse into subdirectories.

the other or last part,
(/out/basic[azure]/src/ during setup)
I understand to mean pretty much the same as the first action but it make references to [B]setup[/B] which is of course what I am doing. Could this second part mean something completely different? it is a little ambiguous.

I am still stuck with the previous message issue - no change

Thanks in advance for the miracle and regards from down under
Don_in_OZ aka NHWS

this means, if you have a alternate Azure-based theme, you have to set additional the /src folder from Azure writeable while setup

In your case (using original Azure) you just have to set it writeable all time.

…I just came across another idea…

You wrote, that you have uploaded and installed via CPanel first? Maybe the File-Owner or group differs from the apache / www -User? And therefore this user can not access when the shop / www-user wants to execute something?

Check this issue with uploading a file via ftp-client and compare the owner of this file with the previous file-owners.

:confused:

The server is running Apache and I have checked with the domain hosts who advised that I could not see the .htaccess file because an option to hide all ‘dot’ files was in place.

The access rights have been checked multiple times and whilst I have been advised that leaving the access to 777 is extremely dangerous in terms of hackers, all the troubleshooting notes have been followed to the letter.

Has anyone else ever come across this problem before and is the a way of debugging the complete file? Perhaps someone has a module developed already although my searches have resulted in nothing so far.

I am disappointed because I am close but then again so far… :frowning:

Don_in_OZ aka NHWS

Try to put an echo before imodstat=0 to find the folder with insufficient rights:
http://www.oxid-esales.com/forum/showthread.php?t=5017&page=2#post30655

Thanks again to those who have offered help to resolve this problem.

It appears what the software is stating is that there was a folder permission issue OR and this is KEY, a security compromise.

OXID detects (and rightly so) that once the installation is complete if config.inc.php and .htaccess files are still writable it will flag this as a security compromise, once they are set to read only the compromise no longer exists.

In my case I requested help from the server administrator of the Apache software and cPanel. He described the solution as follows:

[I][B]OXID was suggesting full permissions on all users to allow itself to write to the following directories, out, log, tmp, and export.

As a lesser of two evils, I have given the web daemon group write permissions rather than allow all users write access. Once the install is complete .htaccess and .config.inc.php have to be set to read only or it flags it as a security compromise. The system health check now passes but I am unable to test its functionality, If problems arise I suggest reinstalling it without deleting the directories (but delete sub-dirs inside) and revert config.inc.php and .htaccess to world writable (777) and try again.

[/B][/I]

I further questioned the meaning of his explanation and he replied as follows:

[I][B]Its a username on the web server itself. I changed the permissions via the shell rather than using cPanel. cPanel does not allow you to change ownership but I think changing ownership is cleaner than just setting world writable permissions. Making those directories world writable more or less achieves the same outcome though.

The key is making those directories writable to the webserver otherwise OXID cannot create/update the files.[/B][/I]

I have posted this information to share with the forum so that the senior members may understand how a resolution to my particular problem was achieved and so that they may assist others in future, if a similar problem arises.

Thanks again

Don_in_OQ aka NHWS