Nextcloud version : 18.0.3
Operating system and version: Linux 3.10.0-1062.9.1.el7.x86_64
Apache or nginx version: Apache 2.4.43
PHP version: 7.3.16
The issue you are facing:
I have long had a cron job set up to run cron.php every 15 minutes. Some time yesterday it started failing with, “Could not open input file: /home/username/hostname/cron.php”. The file cron.php still exists in that location, and it appears to be intact. Has anyone else ever encountered this?
Is this the first time you’ve seen this error? (Y/N): Y
Steps to replicate it:
Set up a cron job to call cron.php (in my case, /usr/local/bin/php -f /home/username/hostname/cron.php
Have it run just fine for years
Suddenly one day out of the blue it starts failing with, “Could not open input file: /home/username/hostname/cron.php”.
The output of your Nextcloud log in Admin > Logging:
Ask a supporter which phrase he has heard most often, it is “I haven’t changed anything …” If the file exists in that directory, make sure that it is accessible and executable by the web servers user. Most likely the access and ownership rights of the file or a folder in that path has changed. The easiest way to debug such a behavior is, to switch to the web server user, walk along the path to the file and try to open/execute it.
I have not, but my hosting provider suggests reviewing the PHP command for compatibility with PHP 7.3, so I’m looking into that.
I’m using shared hosting, so I have no SSH access.
The cPanel cron service e-mails me when the command fails, so the error message is in that e-mail.
In fact, I did notice that. The recommendation used to be 15 minutes. Any idea why it has been changed (in what, v18?) to 5?
Reasonable suppositions, but I have, in fact, already checked both the owner and permissions of the file and folder in question, and there has been no change to either.
The default frequency changed back in one of the NC17 versions and had been carried forward to the current NC18 release. I’m not sure why it has changed, still looking for an explanation.
Can you please make a screenshot of your Nextcloud root folder file structure (either via your desired FTP program or the file browser in cPanel) and post this here?
It would be ideal to see the user:group and the permissions of the files in your NC root folder.
And you are sure that you have not installed / updated anything on the server lately?
Sure, here it is, although cPanel’s File Manager view does not show the owner user or group. Where in cPanel can that be viewed, for that matter? The “Settings” of File Manager don’t offer me any more column choices.
I see cPanel now offers a “Terminal” where one can apparently use regular Unix filesystem commands (ls, etc.). In that interface, I see files and folders have owner and group which is my actual username (let’s call it foo/foo). However, the root folder of my NC instance does not contain any of the files I expect to see. It shows only a cgi-bin folder. So, I have one view of the NC instance in the File Manager, and another in this Terminal. Strange; I would imagine that I’m using cPanel as the user foo in question, I would expect to see the same files in this Terminal.
Continuing with the idea that this could still be a permissions issue, I set cron.php to be 666, so any user on the system should be able to read it. The directories in the path are all 755. Even so, the command still fails with, “Could not open input file”.
Hm, I created a new cron job which did nothing other than ‘touch /home/username/testfile’ and although it seems to have succeeded I cannot see that file in cPanel’s File Manager, so cron and cPanel would seem to be running with some differing privileges. Will have to wait what my hosting provider says about it, if anything.
Following your clarification of what my provider means by “php-pm73”, in cPanel’s MultiPHP Manager, I can see that my root domain (e.g., example.com) has PHP-FPM enabled, but my Nextcloud subdomain (e.g., nextcloud.example.com) has it disabled for some reason. I appear to have no possibility to enable this myself. Both root and subdomain are using PHP 7.3 (ea-php73).
So, my question now is do I need to 1) ask my provider to enable PHP-FPM, or 2) somehow modify my cron job so it works using PHP-PM, instead? The latter does seem to be what my provider is suggesting by his reference to “use php-pm73”.
Here you can find the PHP-PM project - They claim that it boosts the performance up to 15x compared to PHP-FPM, so that’s probably the reason why your provider suggests to use PHP-PM instead of PHP-FPM.
As for your questions, if you are paying for web hosting, these things need to be enabled by your provider. You can always ask them, if they already suggest to use PHP-PP, if they could enable it for your hosting plan.
Well, I can’t say the end result of this case is very illuminating, but after a brief downtime of my domain and cPanel the same cron command now succeeds. It may be that my provider fixed something, but I have no idea.
It still seems most likely to me that cron was simply not running as the correct username
If the file exists in that directory, make sure that it is accessible and executable by the web servers user. Most likely the access and ownership rights of the file or a folder in that path has changed. The easiest way to debug such a behavior is, to switch to the web server user, walk along the path to the file and try to open/execute it.
