Executing scripts through CRON with error after update

Virtualmin
1

Hello,

I recently updated my server to the latest version of Virtualmin (7.9.0). Since then, I’ve noticed that I can’t run PHP scripts in crontab that involve the simple creation of a file in the user’s folder.

The most striking thing is that, when I execute the script via CLI “manually”, the script works perfectly. However, when trying to execute the script through crontab, I’m faced with the following error:

PHP Warning: file_put_contents(test.txt): Failed to open stream: Permission denied in /xxxxxxx/test/test.php on line 4

The script I’m using is a PHP test to try to understand exactly what’s happening. The PHP script is as follows:

<?php
$file = 'test.txt';
$content = "Writing test\n";
if (file_put_contents($file, $content) === false) {
    echo "Failed to write to file";
} else {
    echo "File written successfully";
}

Initially, I thought it might be some incompatibility from the recent update with other packages installed on the server – for that, I updated all the system packages.

I also took care to recheck the permissions of the user’s folder (even recursively) but it didn’t help (by the way, it doesn’t seem to be a permission problem in the folder, since the script works when triggered manually – via CLI).

However, the error persists.

Does anyone know if any directive has changed with an update? I’m even considering some new PHP directive that I’m not aware of.

Tks

System Information
os: Ubuntu Linux 20.04.6
theme version: 21.09.5
virtualmin version: 7.9.0.gpl-1
webmin version: 2.105
Related packages: cron

2

why not add at the beginning of the script

$processUser = posix_getpwuid(posix_geteuid());
echo "running as user {$processUser['name']}\n";

this will just inform you if the script is running as the user you expect it to be, if it’s not the user you expect look at the cron job user

3

Has this function evolved a little and it now fails “false” if the FILE_APPEND directive is not specified when the file already exists?

As if you say it works CLI, perhaps the file needs to be deleted if it exists prior to writing again?

Can it be done the old safer way using fopen() & fwite()

file_put_contents($file, $data, FILE_APPEND | LOCK_EX);

4

I would doubt you would get this warning from php as the default is overwrite

5

Thanks for the tip, but it seems crontab is executing the task with the correct user (gdiuser):

running as user gdiuser
PHP Warning:  file_put_contents(test.txt): Failed to open stream: Permission denied in /xxxxx/xxxxx/teste/teste.php on line 6
6

Considering that it is a test to identify the problem, I am not even working with overwriting an existing file.

the file that should be created by this test script (‘test.txt’) does not exist in the folder.

7

So i guess gdiuser has the correct permissions to access the resource you are requesting… i could add some extra lines of code so you can see the actual permissions the location is capable of

8

I just ran the following code… it both created the file successfully, it also overwrote it many times.

<?php

$processUser = posix_getpwuid(posix_geteuid());

echo "Running as user {$processUser['name']}<br><br>";

$file = 'test.txt';
$content = "(contents)";

if (file_put_contents($file, $content) === false) {
    echo "File write failed.<br>";
} else {
    echo "File write successful.<br>";
}

?>
9

Looks like you were running that script from web server (br tags everywhere) That is not what the OP is doing. Tbe OP mentions the script runs perfectly from the command line but not as a cron. No doubt if the OP ran the code through the web server it would work

1 Like