I am on a shared server and have set-up a friendica instance. So far everything works fine, except the cron-job.
Each time the cron-job has been triggered, I receive the following error message:
#!/usr/bin/env php ERROR: folder view/smarty3/ must be writable by webserver.
First, I thought the access rights of the folders would create the problem, but I was told that my .htaccess would create that problem.
Since I am not the expert on that, I would like to ask you for your support. I have copied my .htaccess, maybe you can have a look if you see something strange.
Appreciate your help
Cheers Tom
Options -Indexes
AddType application/x-java-archive .jar
AddType audio/ogg .oga
#AddHandler php53-cgi .php
<FilesMatch "\.(out|log)$">
<IfModule authz_host_module>
#Apache 2.4
Require all denied
</IfModule>
<IfModule !authz_host_module>
#Apache 2.2
Deny from all
</IfModule>
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine on
# Protect repository directory from browsing
RewriteRule "(^|/)\.git" - [F]
# Rewrite current-style URLs of the form 'index.php?pagename=x'.
# Also place auth information into REMOTE_USER for sites running
# in CGI mode.
# If you have troubles or use VirtualDocumentRoot
# uncomment this and set it to the path where your friendica installation is
# i.e.:
# Friendica url: https://friend-book.org
# RewriteBase /
# Friendica url: http://some.example.com/friendica
# RewriteBase /friendica/
#
#RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?pagename=$1 [E=REMOTE_USER:%{HTTP:Authorization},L,QSA]
</IfModule>
Hi Droopsnoot,
the cron-job is provided by the hosting platform. It runs with a https://friend-book.org/bin/worker.php command on the same hosting platform. I cannot connect via SSH or sudo.
Very rarely, like once a day, the job runs without a problem and I get:
#!/usr/bin/env
else I receive
#!/usr/bin/env php ERROR: folder view/smarty3/ must be writable by webserver.
thanks a lot for your reply.
Actually, I did not change anything in the script, it comes fright from the installation. What would you suggest?
Thanks a lot
Tom
I’m not familliar with the script and I don’t even know what it’s supposed to do. But typically authentication involves something like:
API_user: 'tom3'
API_key: 'fu5dkk58ahk2g56d'
somewhere in a configuration file that is sent along to the API server. When everything is current and valid the API server should authenticate the request and give it permissions to run the server script.
If your configuration is correct, and it works sometimes but not other times, maybe you’re exceeding rate limits or maybe sending a problem payload?
What is that script meant to do? What kind of payload is being sent / received?
Hi Mittineague,
I really appreciate your reply, thank you.
The worker.php triggers several activities to maintain the system, e.g. deletions, empty chache, etc.
I have copied the worker.php. but I cannot find anything unusual:
#!/usr/bin/env php
<?php
/**
* @file bin/worker.php
* @brief Starts the background processing
*/
use Friendica\App;
use Friendica\BaseObject;
use Friendica\Core\Addon;
use Friendica\Core\Config;
use Friendica\Core\Worker;
// Ensure that worker.php is executed from the base path of the installation
if (!file_exists("boot.php") && (sizeof($_SERVER["argv"]) != 0)) {
$directory = dirname($_SERVER["argv"][0]);
if (substr($directory, 0, 1) != "/") {
$directory = $_SERVER["PWD"]."/".$directory;
}
$directory = realpath($directory."/..");
chdir($directory);
}
require_once "boot.php";
require_once "include/dba.php";
$a = new App(dirname(__DIR__));
BaseObject::setApp($a);
require_once ".htconfig.php";
dba::connect($db_host, $db_user, $db_pass, $db_data);
unset($db_host, $db_user, $db_pass, $db_data);
Config::load();
// Check the database structure and possibly fixes it
check_db(true);
// Quit when in maintenance
if (Config::get('system', 'maintenance', false, true)) {
return;
}
$a->set_baseurl(Config::get('system', 'url'));
Addon::loadHooks();
$spawn = (($_SERVER["argc"] == 2) && ($_SERVER["argv"][1] == "spawn"));
if ($spawn) {
Worker::spawnWorker();
killme();
}
$run_cron = (($_SERVER["argc"] <= 1) || ($_SERVER["argv"][1] != "no_cron"));
Worker::processQueue($run_cron);
Worker::unclaimProcess();
Worker::endProcess();
killme();
Assuming you and he are one and the same (I can’t read German so I’m not 100% certain, but it sure looks like it), did the replies there solve your problem?
I don’t see how the .htaccess file could have anything to do with this error as your script seems to be running in the command line and .htaccess files only influence Apache and not the command line.
To me it seems like the script wants to render some Smarty template but can’t because it can’t write cache files. Which would indeed be a permission problem. Which user is running Apache and which user are you using to run cron? Have you tried running cron as the user Apache is running under? If my assumption is correct that should work.
thanks a lot for your reply.
As friend-book is hosted with a provider the cron-job is steered by the providers system, so I (with my knowledge ) cannot look-up by which role that job is performed.
Concerning the access: in desperation, all files are temporarily set to 777, which should give complete access to folders and and files.
That’s a good temporary measure, but when you find that works I would contact the host with your findings and ask them to fix it correctly for you, as having a directory that’s wide open to anyone isn’t the greatest idea
Admittingly, I feel a little embarrassed, because it was so simple.
Since last night, I have now SSH access to my server and what I did was simply a restart of the system. Since then the error has disappeared.
Thanks to everybody for helping me solving this problem BR Tom
how right you are.
Cheers Tom