IIS 8.5 Upgrade Permissions 7.8.31

SuiteCRM Forum - English Language Installation & Upgrade Help
1

I’ve a 7.8.31 Install running on Server 2012 R2, IIS 8.5, PHP 7.1.1 and MySQL 5.7.18.

Previously I’ve had success upgrading through several versions to get to 7.8.31, now I cannot upgrade past 7.8.31 due to the Upgrade Wizard reporting Bad File Permissions.

I’ve tried many of the relvant solutions listed here but cannot get the Upgrade Wizard to pass the permissions check. The Database and the System Passes Checks.

All files in the Webroot show as Bad Permissions, for example;

Filename Permissions Owner Group
C:/…/Webs/Suitecrm.DS_Store 0666 0 0
C:/…/Webs/Suitecrm.htaccess 0666 0 0
C:/…/Webs/Suitecrm\application_files.tgz 0666 0 0
C:/…/Webs/Suitecrm\campaign_tracker.php 0666 0 0
C:/…/Webs/Suitecrm\composer.json 0666 0 0

I’ve used ICACLS to set/reset the AppPool/suitecrm as the Owner with Full Rights, the server lists the AppPool/suitecrm as the Owner with Full Rights, IUSR, Network Service, System all have Full Rights. In anycase this was all working fine until I got to 7.8.31, I hadn’t changed anything on the server prior to this upgrade attempt.

I’ve applied the SuiteCRM Upgrade Patch v1.0.

Nothing I do changes the outcome of the Upgrade Wizard check, 0666 0 0 is always the outcome of the check, even if I deliberately apply wrong permissions, change the owner or alter system permissions the Upgrade Wizard reports the same Bad Permissions 0666 0 0.

Any suggestions would be greatly appreciated.

2

For those interested.

I’ve prepared a clean test install of 7.10.26, then ran the Upgrade Wizard, All Permissions reported as OK, but I was not able to upgrade to 7.10.27 with the upgrade failing at the Commit stage. There was no obvious errors logged and after trying to Commit the site is HTTP 500.

So I wiped the site and prepared another clean install of 7.10.26. This time I first applied the SuiteCRM Upgrade Patch via Module Loader, then ran the Upgrade Wizard which this time reports Bad Permissions are shown above.

I’ve not yet found anything to indicate in more detail what is going wrong.

3

Are you a PHP developer?

I think this is a bug, but I am not sure if the bug is in the new SuiteCRM code in the patch, or if it is in PHP itself (on windows only).

If you can catch the PHP permission function returning wrong values, that would be great. I believe this happens at the root directory level.

Note that PHP functions deal with permissions like 775, but that’s a Linux-style permissions logic. It simply does not apply in Windows. So whoever did that is trying to squeeze some equivalent Linux values from Windows permissions, and it’s not working very well…

If you are not a PHP developer, ignore this post

4

Hi pgr,

Thanks for the reply, I’m not a dev but I’m going to run some tests and see if I can add to the knowledge base. If you want to know why please read on.

I had applied SuiteCRM Upgrades to our instances about four weeks back, I moved the live instance to 7.8.31 and cloned it to a Dev instance which I then upgraded to 7.10.27. This is just how I try to keep ahead of problems, I always have a Dev instance on the next version I will target. My intent was to get the production instance to LTS 7.10.27 over the coming weeks. FYI, I did need to do some ACLs stuff when applying the 7.10.27 Upgrade to Dev, for some reason IIS Manager Gui doesn’t correctly apply some permissions that needed to be changed for the 7.10.27 Upgrade to work.

Just after this we had a server problem, somebody had clicked a ransomware link encrypting a share, so our IT support staff to be safe restored the whole server(ESXi Snapshot) to a state just before the infection and also before my upgrades, winding back my work by about a week. However, after the server restore they also patched the server locking it down a lot tighter than before.

When I went to repeat the SuiteCRM Upgrades I ran into the new problems, the Upgrades I’d ran before now failed to complete. I repeated all the ACLs changes and applied the Upgrade Patch as before, but they now made no difference and/or intrduced the Bad Permissions problem.

I thought the problem might be the server lockdown changes. So I ran clean installs of a SuiteCRM test instance and they work fine. I seem to be able to make trivial SuiteCRM Upgrades to the test instance, for example from 7.8.x to 7.9.x, but I can’t get the next step of 7.10.27 to complete. So I ran the Upgrade Wizard Patch on the test instance and found the new Bad Permissions error 0666. Which I now realise has exposed that the SuiteCRM version on the restored server, my live instances, already has the Upgrade Wizard Patch in place. So it must have been working or ineffective prior to the server restore and patch. As a result my production instances are now locked on 7.8.31 and cannot be upgraded!

FWIW, I’ve also tested a clean test instance of 7.10.27 and it seems fine, until the Upgrade Wizard Patch is applied and the Bad Permissions return. I haven’t yet tried Upgrading a clean install of 7.10.27 to 7.11.x without the Upgrade Wizard Patch being present, but at some stage I will.

I can’t do much about the server patches, but I can test PHP versions as they upgraded PHP version from 5.6 / 7.1 to 7.1.1. I suppose I can parallel install 7.0 and see if that solves the problem.

If I cannot get this resolved the next step I suppose is look into migrating data from 7.8.31 to a clean instance of 7.10.27, but I’m not sure that is even possible!

5

Don’t try this, moving data across different versions is never a good option with SuiteCRM.

The bug that’s blocking you is a bug with the screen that does those preflight checks, right? You could try just bypassing it, hack the installer to bypass that check just for this one upgrade. As long as the permissions are really ok, even if SuiteCRM can’t recognize it, the upgrade should succeed. Of course, you should only try this if you have a snapshot to go back to in case it fails.

You could also try really abusive permissions (everyone: full control) just for the duration of the upgrade. But actually I think the bug would still block you. Actually this would be a nice way to test it, and confirm it’s a bug.

6

Noted pgr, thanks for the advice.

Prior to the upgrade wizard patch the upgrade process fails at the Commit stage with nothing in the log. I get a white panel in the browser and when I try to logout and back in HTTP 500 after the login screen. I’ve not yet found a way around this, but it looks like when the file copy/upgrade begins the process hangs at some stage with no log entry, before that all activity is logged and seems fine. So maybe permissions or server security is an issue.

After the upgrade wizard patch is installed the preflight fails at bad permissions, no matter how generous the permissions are set, I’ve tried giving a cloned instance Full Admin rights on both the files, folders and IIS AppPool, and it still fails.

I suppose I could launch a Linux VM on ESXi of equal SuiteCRM version 7.8.31 to the Windows machine, migrate the database and webroot to Linux and perform the upgrades to 7.10.27, then migrate the database and webroot back to the IIS under the clean install of 7.10.27. It would be laborious but it is probably a work around as long as I carefully match various versions. Of course I may trip up on some platform incompatibility, but I’ll have to try if I can’t get past this upgrade roadblock.