Upgrade 7.11.13 to 7.11.15 fails at systemcheck on windows

So - after several hours of trying to solve this - this is clearly a different bug. It is NOT a bug related to file permissions its a messed up upgrade system in SuiteCRM.

I have a demo instance on suitecrm on the same server, same XAMPP, same user etc. I recreated everything under security in windows to be the exact same as my demo suitecrm. It is the same now yet the upgrade doesnt work…

So I am stuck :frowning: I can’t update our CRM anymore :frowning:

Just to clarify - my demo can update easily - the conflict files have EXACTLY the same security setup as live CRM files - when I compare it it has same owners, same users, same rights. Everything is exactly the same in my demo and live CRM. But demo updates easily yet live CRM says wrong files with 0666 and it is talking about ALL files in root folder of CRM.

I really have no idea how to proceed here…

It messed up right after I used the suitecrm upgrade repair patch… Until then it was all good.

OK - so the upgrade is clearly failing. Let’s try and isolate the cause of the problem. The ‘repeated’ and reproduce able failure to do something means that there is a cause. Unfortunately at the moment we’re missing it.

So far, people are going to find it difficult to help you due to lack of information. We need you you be accurate about what fails and the error you get. This site is a really useful read:

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Blockquote
So - after several hours of trying to solve this - this is clearly a different bug. It is NOT a bug related to file permissions its a messed up upgrade system in SuiteCRM.

Why do you say this? Generally there’s a good reason for a check to be made before an upgrade, in order to identify problems that might cause an issue, so that you get a clean upgrade rather than a broken system that you have to recover.

Blockquote
At the systemcheck the upgrade fails with a permission error for all files directly under htdocs

implies that the issue is related to permissions. So, let us start trying to diagnose the true cause of the problem:

  1. What is the EXACT wording of the error you get? If we know the EXACT error, then we can grep through the code, and check what causes it, and find out the exact check that failed.

  2. What had you done to get to this point where you get the error. I’m presuming that you went through the normal 'web based upgrade process? Or did you try out the robo upgrade route?..or did you try manually applying the patch?

  3. Can you provide a link to the ‘corrective patch’ that you applied? There are often different versions of patches for different versions of the base software.

Clearly something is different, or the 2 instances would behave exactly the same, so we’ve got to locate that difference and try to correct it. The more information that you give us, then the easier it is for us to provide pointers that will help you to fix the problem. Feel free to try experimenting with uploading a screen shot of the error, as ‘a picture is worth a thousand words’ as they say :slight_smile:

Version compatibility matrix:

Looks OK to me.

Yeah compatibility is not a problem. I will create a complete report including screenshots and post it here. :wink:

Try to install XAMPP on another computer and try to upgrade there. IF works then you transfer upgraded DB and files to your main server.

Thanks,

BrozTechnologies

So, here are some screenshots. Basically - what happened is this:

  1. I wanted to update from 7.11.13 to 7.11.15.
  2. Downloaded a proper upgrade file
  3. There was an error before update - this one (first post):

So the update never really started. At this point I downloaded an upgrade patch from here:

https://suitecrm.com/files/162/SuiteCRM-7.11/507/SuiteCRM_Upgrade_Patch.zip

As suggested by pgr here:

And then I uploaded and installed it. Then I tried another update.

  1. at this point the previous bug disappeared and instead I see this. I didnt change any file permissions, it happened right after upgrade patch installed :frowning:

So - basically, I think the upgrade patch messed up something in upgrade system, thats why its seeing files with bad permissions even if they do NOT have bad permissions…

1 Like

Also one thing to note - I tried web update. Dont know any other… Might be worth a shot doin it manually but I didnt find anything about that…

Awesome bug/fault description. Firstly, the 0666 on a windows system is absolute rubbish - it’s a simplistic view on the file system designed to make it look more like a *nix system.

The key bit here is that the web server DOES NOT have the necessary permissions to access the files concerned.

My hypothesis is that you ran the upgrade patch as a user with windows administrative permissions, which has tried to ‘fake’ ownership of the files in some way. Your particular problem is almost certainly going to be of interest to other people who use an XAMPP system because the developers work on *nix based systems and permissions work differently with them. On a *nix system the owner and group of 0 would imply rw (user) rw (group), rw (other), BUT if the containing folder was 666, then no other user would be allowed to browse into that folder. On a *nix system the folder needs to have the appropriate settings to allow the contents to be viewed. A common setting for a folder would be 755, or 777 (for full access to everyone and everything). Obviously be careful about granting unnecessary access permissions.

So - let’s test this and correct as appropriate.

If you browse to your web root in file explorer and check security permissions on the files concerned. Here is a fairly good overview:

In order to solve your problem, you will then need to add the webserver (or potentially fpm-php? depending on how you’ve done the configurations) to the Security Groups allowed access to those files and the containing folders. Make sure that the security group associated with the webserver has read AND write permissions.

If you’re not sure what you’re doing, then the safest way might be to change the permissions on just one of the reported files and then check whether it removes that file from the pre-flight check.

OK soo… this is all messed up. So what I tried is this:

I took the whole CRM with DB, pasted it to my local PC where I also have xampp. (default xampp install, no adjustments). It has the same problem here as well!

So I tried playing with folder permissions and I found out one thing. When I use myself (my account name) as an owner - it still has this bug. All the files except for root folder files are accessible. But when I take those root files one by one and change their owner to “Administrators” then when I repeat the pre flight check in suitecrm - those files are no longer in bad permission files list.

But I am affraid thats only because suitecrm can’t access those files anymore… Because when I change .htaccess in the same way (.htaccess is one of the root files with bad permissions problem) then I can’t access CRM anymore…

So it seems that the upgrade patch changed the way preflight check works. I tried every possible combination. I also tried to take one of the bad files and I gave it ALL security groups my windows has and I checked Full control for all of them. Nothing changed.

I remember that when I installed the upgrade patch - I did it remotely. Meaning -> I was on my local PC, I accessed CRM as any other website and did upgrade patch. Now I am thinking that if I were to do it directly from server where CRM is installed it might work in a different way but unfortunately - I can’t uninstall the upgrade patch. See the screenshot. Is there a way to remove the upgrade patch and try to install it again?

I also wonder what would happen if I take all the affected files from my demo, adjust config and htaccess accordingly and simply delete all of them from live CRM and paste the ones from my working demo CRM… But that will probably mess up something (considering my demo is on newer version of CRM - the update went well there)

This is unlikely to work as the other machine will have different U/GUIDs for each user, even if the operating system displays the same human readable account name.

This is because I’d expect that the web server in an XAMPP system is going to be part of an Administrative group, hence when you change it to Administrator as the owner, the Administrators Group (including the webserver) also gets gets access to the file.

Ideally if you can find the correct user for the webserver (probably apache?) then change the owner to that, but in order to get yourself up and running recursively changing the webroot folder ownership to the Administrative user should be enough to enable you to carry out the upgrade process.

Please not that XAMPP is considered to be for test and development use only. See:
https://www.apachefriends.org/faq_windows.html
“Is XAMPP production ready?” - Therefore use in a production environment at own risk.

With respect to removing patch and restoring, it may be possibly to create a full backup:
index.php?module=Administration&action=Backups

…and then restore to the same version and start the process again from a clean install of the SAME suiteCRM version, but I’m not familiar with how this would work on an XAMPP setup. What it would do is give you a clean start with the correct apache webserver permissions.

Hey @anothermouse thanks a lot really for trying to help.

Btw - I have news! I was crawling through files and I found out that when you upload upgrade patch it creates a restore point. What it does is - it takes all files that it replaces (from module UpgradeWizard) and saves it in a restore folder.

So I took those files and I replaced my upgrade wizard files with restored ones. And the rights problem is GONE!!! I am back on problem nr. 1 but this means that the file rights were never wrong! Its a messed up upgrade patch script.

Now I have my original problem which is - when I do preflight check it says:

Fatal error: Uncaught Error: Cannot use object of type SplFileInfo as array in F:\xampp\htdocs\crm\include\utils\file_utils.php:57 Stack trace: #0 F:\xampp\htdocs\crm\modules\UpgradeWizard\uw_utils.php(4590): clean_path(Object(SplFileInfo)) #1 F:\xampp\htdocs\crm\modules\UpgradeWizard\systemCheck.php(83): dirInArray(Object(SplFileInfo), Array) #2 F:\xampp\htdocs\crm\modules\UpgradeWizard\index.php(292): require('F:\\xampp\\htdocs...') #3 F:\xampp\htdocs\crm\include\MVC\View\SugarView.php(834): include_once('F:\\xampp\\htdocs...') #4 F:\xampp\htdocs\crm\include\MVC\View\views\view.classic.php(72): SugarView->includeClassicFile(Object(SplFileInfo)) #5 F:\xampp\htdocs\crm\include\MVC\View\SugarView.php(226): ViewClassic->display() #6 F:\xampp\htdocs\crm\include\MVC\Controller\SugarController.php(435): SugarView->process() #7 F:\xampp\htdocs\crm\include\MVC\Controller\SugarController.php(375): SugarController->processView() #8 F:\xampp\htdocs\crm\include\MVC\SugarApplication.php(113): SugarController->execute() #9 F:\xampp\ht in F:\xampp\htdocs\crm\include\utils\file_utils.php on line 57

So we are back in this thread (so I did not exactly hijack it :smiley: )

Basically - 7.11.13 has upgrade bug on windows and the suggested repair (upgrade patch) has bug too so its impossible to upgrade 7.11.13 on windows at the moment.

OK - as per that link, there are instructions on how to identify what is causing the problem in that particular routine.

Once we know what the path is, we need to find out how it got there. One obvious place that there could be an issue is in your configuration file … config.php

If you post the output from the logging as detailed in that link, then we can start trying to locate the cause of the problem. The fact that you’ ve managed to carry out a clean upgrade on a simple install implies either a bug that might be worth checking in the latest version, or potentially a typo in something important somewhere. :thinking: As we’ve got at least 2 people with the same problem, it’s worth looking at a bit more closely. A pity that the other person didn’t get back to us, so that we can all learn from it. :frowning_face:

Well I continue in this thread as it is more relevant now:

Apache/2.4.26 (Win64)
OpenSSL/1.1.0f
PHP/7.3.9
Server version: 5.6.23 - MySQL Community Server
Server charset: UTF-8 Unicode (utf8)

I have this configuration a long time and never had issues

I believe the error is related to the PHP version.

For more information please check the related documentation here:

Thanks,

BrozTechnologies

I am having the same issue trying to upgrade from 7.11.13. My PHP version is 7.3.0, which according to the Compatibility Matrix, is supported. Is there a new upgrade patch?

try installing the latest Upgrade Patch 1.0.1 available here–> Upgrade SuiteCRM - SuiteCRM
and see if that helps

1 Like

Thank you so much for this! It is exactly what I needed. I have successfully upgraded now.