Fatal error: Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given

photomike · July 24, 2024, 10:42am

Installing on remote VM,
Alma Linux 5.14.0-427.22.1.el9_4.x86_64 (from uname -a)
PHP 8.2.21 (cli)
mariadb Ver 15.1 Distrib 10.5.22-MariaDB, for Linux (x86_64) using EditLine wrapper
Apache2 (httpd) version not shown.
(each from {package name} --version)
MODX-3.0.5 downloaded from MODX download site.

Unpacked the MODX zip file and moved the contents to the document root (html). I’d already set the cache and setup permissions to 777, opened mikegoodmanphoto.com/setup in FF. Entered the DB settings, test passed, entered the administrator settings, test passed, hit the ‘NEXT’ button and got the following response in the browser:

Fatal error: Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /var/www/imagetalk.mikegoodmanphoto.com/html/setup/includes/test/modinstalltest.class.php:490 Stack trace: #0 /var/www/imagetalk.mikegoodmanphoto.com/html/setup/includes/test/modinstalltest.class.php(490): fwrite() #1 /var/www/imagetalk.mikegoodmanphoto.com/html/setup/includes/test/modinstalltest.class.php(52): modInstallTest->_checkConfig() #2 /var/www/imagetalk.mikegoodmanphoto.com/html/setup/includes/modinstall.class.php(251): modInstallTest->run() #3 /var/www/imagetalk.mikegoodmanphoto.com/html/setup/controllers/summary.php(27): modInstall->test() #4 /var/www/imagetalk.mikegoodmanphoto.com/html/setup/includes/request/modinstallrequest.class.php(81): include('...') #5 /var/www/imagetalk.mikegoodmanphoto.com/html/setup/index.php(30): modInstallRequest->handle() #6 {main} thrown in /var/www/imagetalk.mikegoodmanphoto.com/html/setup/includes/test/modinstalltest.class.php on line 490

At an earlier attempt I didn’t set up the database in MariaDB and got no response at the first test stage. So I set the database up with name, username and password before running setup this time. Other than that I have done nothing. The only item in the cache directory at the start was the setup directory.
I don’t understand PHP but this doesn’t look like an xPDO issue, of which there are lots reported around the web.

Thanks in advance for helpful responses by way of hints, questions or answers,

Mike

halftrainedharry · July 24, 2024, 11:35am

The error occurs on this line:

github.com

modxcms/revolution/blob/482c68d4d6bd01961ffcdd8c4f26a51d96dd69c7/setup/includes/test/modinstalltest.class.php#L490


      
           * Config file writable?
           */
          protected function _checkConfig()
          {
              $configFileDisplay = 'config/' . MODX_CONFIG_KEY . '.inc.php';
              $configFilePath = MODX_CORE_PATH . $configFileDisplay;
              $this->title('config_writable', $this->install->lexicon('test_config_file', ['file' => $configFilePath]));
              if (!file_exists($configFilePath)) {
                  /* make an attempt to create the file */
                  @ $hnd = fopen($configFilePath, 'w');
                  @ fwrite($hnd, '<?php // ' . $this->install->lexicon('modx_configuration_file') . ' ?>');
                  @ fclose($hnd);
              }
              $isWriteable = @is_writable($configFilePath);
              if (!$isWriteable) {
                  $this->fail(
                      'config_writable',
                      $this->install->lexicon('failed'),
                      $this->install->lexicon(
                          'test_config_file_nw',
                          ['key' => MODX_CONFIG_KEY]

The code tries to write to the file core/config/config.inc.php that was created the line above. But creating the file (with fopen) wasn’t successful (and returned false). Maybe a permissions issue?

bobray · July 24, 2024, 10:09pm

777 is not a good choice for a number of reasons, partly because it often doesn’t work with PHP. The MODX recommendation for folders and files is 755 / 644 respectively.

photomike · July 25, 2024, 9:35pm

@halftrainedharry @bobray thanks both for the replies. I’ve been doing some digging and also changed the directory permissions to 755. Files were already at 644. Other than that I can’t say I’ve found anything useful.
The current directory/file list with permissions and ownerships are printed below.
A couple of things I’ve noticed:
There is a file named config.inc.php in the document root (html). Is that in the right place, should there be another created in /core/config/?
Most of the files are owned by root, which on an RHEL clone is correct as the system allocates all root’s files in the /var/ directory to httpd, but some are owned by apache. RHEL and its clones use httpd, not apache. Is this causing errors or is it correct in this, MODX, context?
.htaccess is listed but as ht.access, should that be changed prior to installation?

ls -la html
drwxr-xr-x  6 root root 4096 Jul 23 11:28 .
drwxr-xr-x  4 root root 4096 Jul 23 11:29 ..
-rw-r--r--  1 root root  292 Apr 10 08:18 config.core.php
drwxr-xr-x  3 root root 4096 Apr 10 08:18 connectors
drwxr-xr-x 14 root root 4096 Apr 10 08:18 core
-rw-r--r--  1 root root 2058 Apr 10 08:17 ht.access
-rw-r--r--  1 root root 2130 Apr 10 08:17 index.php
drwxr-xr-x  5 root root 4096 Apr 10 08:18 manager
drwxr-xr-x  9 root root 4096 Apr 10 08:18 setup

html]# ls -la core
total 60
drwxrwxr-x 14 root root 4096 Apr 10 08:18 .
drwxr-xr-x  6 root root 4096 Jul 23 11:28 ..
drwxr-xr-x  3 root root 4096 Jul 23 16:07 cache
drwxr-xr-x  2 root root 4096 Apr 10 08:18 config
drwxr-xr-x  2 root root 4096 Apr 10 08:18 docs
drwxr-xr-x  2 root root 4096 Apr 10 08:18 error
drwxr-xr-x  2 root root 4096 Apr 10 08:18 export
-rw-r--r--  1 root root  363 Apr 10 08:17 ht.access
drwxr-xr-x  2 root root 4096 Apr 10 08:18 import
drwxr-xr-x  2 root root 4096 Apr 10 08:18 include
drwxr-xr-x 34 root root 4096 Apr 10 08:18 lexicon
drwxr-xr-x  4 root root 4096 Apr 10 08:18 model
drwxr-xr-x  3 root root 4096 Apr 10 08:18 packages
drwxr-xr-x  3 root root 4096 Apr 10 08:18 src
drwxr-xr-x 19 root root 4096 Apr 10 08:18 vendor

html]# ls -la core/cache/
total 12
drwxrwxrwx  3 root   root   4096 Jul 23 16:07 .
drwxrwxr-x 14 root   root   4096 Apr 10 08:18 ..
drwxr-xr-x  3 apache apache 4096 Jul 23 15:29 setup


html]# ls -la core/cache/setup/
total 16
drwxrwxrwx 3 apache apache 4096 Jul 23 15:29 .
drwxrwxrwx 3 root   root   4096 Jul 23 16:07 ..
-rw-r--r-- 1 apache apache 2057 Jul 23 16:07 settings.cache.php
drwxr-xr-x 2 apache apache 4096 Jul 23 11:42 smarty


html]# ls -la core/config/
total 8
drwxr-xr-x  2 root root 4096 Apr 10 08:18 .
drwxrwxr-x 14 root root 4096 Apr 10 08:18 ..

rosshaden · July 26, 2024, 2:06am

Check permissions with ls -ld in terminal

halftrainedharry · July 26, 2024, 7:12am

Yes. This file defines the path to your core folder.
The default is define('MODX_CORE_PATH', dirname(__FILE__) . '/core/'); The value then gets replaced with the actual path on your system.

Yes. The installation process should creates the file core/config/config.inc.php which contains your database settings (user, password, db-name) and more paths/URLs.
But the creation of this file fails on your system.

To create a file in this folder, you need write permission (w). In this case only the owner of the folder has write permission. The owner is root.
As you try to create the config file from the browser, what user is Apache running as? If it’s not root, then you have no write permission.

No. You can change it after the installation (for example if you enable friendly URLs).

photomike · July 26, 2024, 8:07am

Thank you for the comprehensive response. Very much appreciated.
Alma is an RHEL clone. On RHEL and its clones everything in the /var/www/ directory, recursively, owned by root is transferred by the system to httpd. httpd, in my understanding, should not be referred to directly.
Also, RHEL and its clones refer to the Apache web server as httpd, not as apache. Hence my question about whether MODX has some sort of exception for this. If not I need to change the existing ownerships from apache to root.

photomike · July 26, 2024, 8:18am

Thank you for the reply. I appreciate you joining the conversation.
‘ls -la’ or ‘ls -ld’? My intention was to show ownership and permissions on all directories and all files in the relevant sections, for which ‘a’ is the correct flag. Note, for instance, my questions re. ht.access and those files marked as owned by apache, coupled with the earlier comments regarding directory permissions.

halftrainedharry · July 26, 2024, 8:32am

Well I’m not a server guy. I very much doubt MODX has “some sort of exception” or any knowledge about how your server is set up exactly.

From a PHP point of view, the code tries to create a file using fwrite and can’t, probably because the user your PHP process is running as doesn’t have permission.

My guess is that you have to change the ownership of the files in the www folder (to match the user PHP uses).

photomike · July 26, 2024, 8:53am

Sincere thanks for this.
Am I correct in thinking this exercise is purely for the installation process? Ownerships and permissions from then on can be more or less left as-is?
In my understanding, which could be misdirected because I lost track with PHP at v4, PHP is in the root group so I need to change the relevant file’s or folder’s permission to 664/775. Surely that wouldn’t entail changing the whole contents of the www folder? Is /core/config/* to 664likely to do the job?

halftrainedharry · July 26, 2024, 9:14am

MODX will have to create additional files in other directories. E.g. core/packages when downloading extras, assets/components and core/components when installing extras, core/cache for all cache files, etc.
You can upload files directly in the MODX manager or create new folders. If you want to upgrade MODX via the “UpgradeMODX” extra, all MODX files have to be replaced with PHP.

You could try only selectively adjusting file/folder permissions (and maybe creating the system settings new_file_permissions and new_folder_permissions), but my guess is that you will continuously run into problems.

photomike · July 26, 2024, 9:34am

I think that pretty well nails it down. 775/664 sound like the obvious way to go. An intruder still has to get into the root group before they can do any damage.

Which still leaves the question of whether to leave the apache ownership attributes in /core/cache/ and /core/cache/setup/ but I’ll cross that Rubicon in due course.

photomike · July 26, 2024, 11:50am

I have a new error.
First, I had to change the permissions on /core/cache/ to 777 or couldn’t make any progress at all. That reproduced the same error as in my OP.
Changing the file ownerships in /core/cache/ and core/cache/setup/ from apache to root elicited

Fatal error: Uncaught --> Smarty: unable to write file /var/www/imagetalk.mikegoodmanphoto.com/html/core/cache/setup/smarty/wrt66a38b8876a7e8_89756431 <-- thrown in /var/www/imagetalk.mikegoodmanphoto.com/html/core/vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_writefile.php on line 54

The Smarty directory is in /core/cache/setup/ and is one of those I amended from apache to root ownership. Now, I may not understand PHP but Smarty has me bemused, baffled, bewildered and running for the hills!
Well, it’s different. Does that indicate progress?

photomike · July 26, 2024, 12:06pm

More progress? I realised the files in /smarty/ were also owned by apache. So I changed those to root and have a more specific error. How do I change the characterset/collation expected by xPDO? The database is set up with utf8 and utf8_general_ci.

[2024-07-26 11:56:13] (ERROR in xPDO\xPDOConnection::connect @ /var/www/imagetalk.mikegoodmanphoto.com/html/core/vendor/xpdo/xpdo/src/xPDO/xPDOConnection.php : 89) SQLSTATE[HY000] [2019] Unknown character set

halftrainedharry · July 26, 2024, 12:19pm

The collation is determined during the setup process (third step: setup/index.php?action=database) when you enter the “Database connection and login information”. It’s then stored in the config file core/config/config.inc.php → variables $database_connection_charset and $database_dsn.

photomike · July 26, 2024, 1:18pm

Contents of my core/config/config.inc.php:

  GNU nano 5.6.1              core/config/config.inc.php                        
<?php // MODX configuration file ?>

I’m trying to install from the automated browser script, which for the DB section asked me for DB name, username and password. Nothing else. I set the DB up manually with MariaDB and set its character set and collation there.

So I’m assuming the script is using the MODX default, also the MariaDB and MySQL default, designed by Monty Widenius, a Finn, which may explain why it’s default is latin1_swedish_ci and not UTF. latin? No, let’s leave it there, we’re getting into slapstick now.

halftrainedharry · July 26, 2024, 1:26pm

You fill in DB name, login name and password, then click on “Test”.
The next part with charset and collation appears:

photomike · July 26, 2024, 1:46pm

That is what I get too. That part repeats what I’ve already set up in MariaDB. I get the errors after the next set of boxes, which ask for administrator details. I fill those in, click the big ‘next’ button and up comes the error.
Apart from the standard ‘.’ and ‘…’ the only entry in core/config/ is config.inc.php with the content as shown above.

halftrainedharry · July 26, 2024, 1:56pm

It looks like during the setup process, the settings are temporarily stored in the file core/cache/setup/settings.cache.php (before they are written to core/config/config.inc.php).

Yes, it reads the values from the DB.

bobray · July 27, 2024, 11:11pm

Note that there should be a config.core.php file in the MODX root directory. MODX needs to read that file to find out where the config.inc.php file is.