ConcreteCMS install missing paths?


I have been attempting to install ConcreteCMS 9.2.0.
Using a manual install to httpdocs folder as per installation.
Host is Plesk PHP 8.1.16, MariaDB 10.6.

Part way through the web install I get the following installation fail:
SessionHandler::read(): open(/var/lib/php/session/sess_a83i2v9jgo19k1b15vsgqhke67, O_RDWR) failed: No such file or directory (2).

As a cross check I unzipped 9.2.0 in Windows 11.
Windows properties shows 143MB, 20845 files, 3528 folders.
I then proceded to upload the extracted folder and files to the Plesk file manager Home folder.
After a lengthy period the upload failed because of missing paths.

Anyone have a problem with the install?

MD5 hashes match.


As @Johnthefish has said elsewhere it pays to wait for one or two revisions of a new CMS until the bugs are ironed out.

So, with that in mind I attempted to do a manual install of ConcreteCMS 9.1.3 on my Plesk host PHP 8.1.16 with MariaDB 10.6.

No luck with the install.
Part way throught the install I get the same error message as in 9.2.0:
SessionHandler::read(): open(/var/lib/php/session/sess_ta9lqjrta7c3ad1maagkf39vjk, O_RDWR) failed: No such file or directory (2).

I don’t want to start using Composer.

I am seriously considering moving to Hostdash or A2hosting which supports ConcreteCMS.

From your plesk file manager, see how much of that (No such file or directory) path exists.

Php (and hence Concrete) tracks data pertinent to each user in a temporary file called a ‘session’ file. The message suggests that your host php setup is not configured to use a directory that your web account php has access to. It is usually a php ini file setting.

This problem will be common to all php applications that keep a session, not just Concrete CMS.

Your host support team should be able to advise you on whether the above suspicion is correct and on how to configure it in your plesk account.

While you have the support team’s attention, get them to also check through the other php ini settings. If they have missed configuring one setting for your account, there could be others (for example, memory allocation).

Thanks John. Your comments have been passed to my Host admin.

Current status:

My website host admin has successfully installed ConcreteCMS 9.2.0 on a Plesk test server.
Plesk PHP 8.1.16 and MariaDB 10.6.

My host admin has asked me to install 9.2.0 of the public server and leave the resulting installtion for examination.

Again I get an error:

SessionHandler::read(): open(/var/lib/php/session/sess_ta9lqjrta7c3ad1maagkf39vjk, O_RDWR) failed: No such file or directory (2)

I note that the MariaDB 10.6 reports Tables 357 and size 13.3MB.

Waiting and hoping to hear of a discovery and solution :smiley:

Are you trying to restore a compressed backup copy of your entire previous site folders and dB?

I’m not sure what the chances of that working would be, especially after decompressing in Windows and uploading. The original file and folder permissions and ownership settings may not survive that process.

If you use your server to compress and then decompress you may have better success…, if permissions and ownership were included in the original compression process.

If I recall correctly, I think one of your other post suggested you were going to install a new empty site and get a fresh start. If that’s an option, does that work? If not, what’s the difference between the host admin’s test server environment and yours?

I have given up on playing about with Windows decompression versus Plesk decompression.

For my attempted installs I am using the Plesk decompression of ConcreteCMS 9.2.0 .zip.

The current investigation is why can’t I install a new empty site using ConcreteCMS 9.2.0.
My website host has successfully installed an empty site using 9.2.0 on a test server.
My attempt to install an empty site on my host server using 9.2.0 still fails.

I am waiting to hear from my host admin about the differences between their test server success and my failed install.

Just received an email from my host admin saying that my issue has been escalated to their engineering team :smile:


Does your Plesk server have reboot (server) or restart (webserver & dB) options. Perhaps it would create a new php session.

I will pass that on to my host admin the reboot options you suggest.

When attempting a new install of ConcreteCMS I have simply deleted all previous files and removed the DB.
Then uploaded a new zip to my host.
Decompressed the the zip and moved the required files to httpdocs.
Then created a new DB.
Then attempted to complete the install using my website URL.

I now have ConcreteCMS 9.2.0 up and running and I am rebuilding my website.
Plesk PHP 8.1.16 and MariaDB 10.6.
My host admin called on their engineers for help.
A new database was created leaving behind my old database.
Further tweaks by host admin a day later allowed me to successfully login and edit my website.
Happy again :smiley:

I’m glad to hear that everything is running with current versions. Did the host admin give any further details on what they thought was wrong with the previous database(s)? If so, please post, it may help someone in a similar situation.

I did ask what the fix was. All I got was that they had created a new database.

After asking my host admin for more details I received:

I’ve asked the Engineer who worked on your Concrete CMS installation and see his response below.

-Create a new database before the installation and delete the old database that was used on failed installation if there’s any
-The server/Plesk should be using PHP-FPM as application.
-And all files permission should be set to 755

My further response:

Thanks for the update… engineers points noted with my comments:

  • I may not have established a totally new DB clear of historical settings, but I did delete any old DB and try a new DB myself.
  • I am using Dedicated FPM app served by Apache.
  • I have noted that there are references to 755 permissions in the ConcreteCMS installation notes. I have ignored these in the past when installing earlier versions of Concrete and have assumed that 1stdomains have these requirements set by default. It seems confusing to me that the Concrete manual installation instructions include Apache CLI type instructions like chmod -R 777 files /*.

Thank you for taking the time to post more detail. I’d defer judgement to other users who know Linux permissions better than I, but I agree…,

“set the apache user (either “apache” or “nobody”) as having full rights to these file. If neither are possible, chmod 777 to files/ and all items within (e.g. : chmod -R 777 files/* )”

Note: no space between “files” and "/" in the directions. Sometimes using the -v (verbose) option for chmod is helpful to verify that it’s doing what you expected.

… seems like something that should be used as a last resort, if that’s what you mean by “confusing”. I’ve never encountered a problem with user permissions when installing via the downloaded compressed version (vs. Composer). I think setting the users to (“apache” or “nobody”) may be an important aspect when resorting to chmod -R 777.

Thanks for your follow up.
The ConcreteCMS Installtion link shows the reference to Linux SU commands which I find confusing especially as I don’t know Linux. I did look at all the manually installed extracted files R/W settings to see that R/W settings were enabled but the “World Writable” requirements must be deeper inside the host’s Linux system.
Anyway I have 9.2.0 up and running and I am rebuilding my website.

1 Like