3.10-r3 - Rights problem with Moodle 3.10.2 (upgraded form 3.8.7, can't update or install Boost Campus) [FIXED]

[StreborStrebor]

Today I attempted a Moodle 3.8.7 to 3.10.2 upgrade (skipping 3.9.5 as My environment is good for 3.10.2 and so is Boost Campus 3.10-r3 (and Boost navigation fumbling 3.10-r3).

Unfortunately I see these errors when updating or installing Boost Campus 3.10-r3: (paths redacted for privacy)

Warning: file_exists(): open_basedir restriction in effect. File(/tmp/requestdir/seyt) is not within the allowed path(s): (/usr/share/php:/home/) in /home//www/***/moodle/lib/setuplib.php on line 1538

Warning: file_exists(): open_basedir restriction in effect. File(/tmp/requestdir/seyt) is not within the allowed path(s): (/usr/share/php:/home/) in /home//www/***/moodle/lib/setuplib.php on line 1548

Warning: is_dir(): open_basedir restriction in effect. File(/tmp/requestdir/seyt) is not within the allowed path(s): (/usr/share/php:/home/) in /home//www/***/moodle/lib/setuplib.php on line 1552

All other plugins upgraded OK, But it's not possible to install Boost Campus / Boost Navigation fumbling.

The exact same Moodle 3.8.7 (rolled back) upgraded without any problems to Moodle 3.9.5 (with Boost Campus 3.9-r6 and Boost navigation fumbling 3.9-r6). So I seem to be stuck on Moodle 3.9.x for the moment (not a problem).

I'm not sure if this is a Moodle 3.10.2 issue, or if it's a Boost Campus (and Boost Navigation fumbling) 3.10-r2

Hope this helps.

[abias]

Hi @StreborStrebor ,

I am unsure if this problem of yours is really induced by Boost Campus, but I would like to point you to https://www.php.net/manual/en/ini.core.php#ini.open-basedir for an explanation of the open_basedir restriction which seems to be involved in the error here.

Looking at the error message, I would like to propose that you add the '/tmp' path to your PHP configuration and try updating the plugin(s) again.

Cheers, Alex

[StreborStrebor]

Hi @abias Alex,

I can't change the open_basedir_restriction, as it's a shared server, so letting everybody read and write /tmp would be a huge security issue.

Something in the install system is simply ignoring the set PHP tmp path ( cause it's NOT /tmp ) and/or the Moodle temp directory in the Moodeldata directory.

I saw this similar thread: https://tracker.moodle.org/browse/MDL-70518

Like Leon in that thread suggests, it could be caused by the introduction of $CFG->localrequestdir in Moodle 3.10.x

His suggestion (not verified it works) is to set the $CFG->localrequestdir tot the Moodledata temp directory "Possibly admins are expected to expllcitly configure $CFG->localrequestdir in these circumstances.

But there's already a temp directory in Moodledata that any otherwise functional site can use – even when there are open_basedir restrictions – I think $CFG->localrequestdir should default to that location i.e. $CFG->dataroot/temp/requestdir."

[nwp90]

It can't do that, as localrequestdir has to be local to the machine, while the Moodle temp dir has to be shared across a cluster...

[StreborStrebor]

I revisited this problem and found the solution. It had NOTHING to do with Boost Campus (my appologies). Here's the fix, for people that have the same issue and will now be able to find the solution to this not very 'archived by Google' Moodle 3.10 issue ;-)

The problem was indeed the fact that my inherited Moodle sites did not have these config values set in moodle/moodle.cfg

$CFG->tempdir = '/home/USERNAME/www/moodledata/temp'; $CFG->localrequestdir = '/home/USERNAME/www/moodledata/temp';

Adding these two config lines fixed all. Now I have Moodle 3.10.x running with the latest Boost Campus and Boost Navigation fumbler.

It seems that since Moodle 3.10 these need to be set. So do this when you upgrade to 3.10 (and presumably higher). The plugin install system does not use the temp directory in the moodldata directory anymore, which is set with:

$CFG->dataroot = '/home/USERNAME/www/moodledata';

Happy it's fixed. Have a great weekend :-)