#!/usr/bin/env php ERROR: folder view/smarty3/ must be writable by webserver

Hi all,

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 !authz_host_module>
    #Apache 2.2
    Deny from all

<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]


Are you taking into account any differences in default directory when your code runs from CRON rather than from the web server?

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:


else I receive

#!/usr/bin/env php ERROR: folder view/smarty3/ must be writable by webserver.

My guess is that the problem isn’t a missing / misspelled file, but a permissions problem.

When I go to friend-book.org I get a login page with a broken hamburger menu. When I click “Community”, I get “Public Access Denied”.

This suggests that the script is not sending the required authentication details.

Hi @Mittineague,

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

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
 * @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."/..");


require_once "boot.php";
require_once "include/dba.php";

$a = new App(dirname(__DIR__));

require_once ".htconfig.php";
dba::connect($db_host, $db_user, $db_pass, $db_data);
unset($db_host, $db_user, $db_pass, $db_data);


// Check the database structure and possibly fixes it

// Quit when in maintenance
if (Config::get('system', 'maintenance', false, true)) {

$a->set_baseurl(Config::get('system', 'url'));


$spawn = (($_SERVER["argc"] == 2) && ($_SERVER["argv"][1] == "spawn"));

if ($spawn) {

$run_cron = (($_SERVER["argc"] <= 1) || ($_SERVER["argv"][1] != "no_cron"));





I’m pretty much at a loss here. I was going to suggest you try friendica support, but I’m guessing you already have

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?

:smiley: how right you are.
Yes, I had it posted there, but the support was pretty thin, so I was surfing and found this forum.

Nevermind, - but let me thank you for your help anyway!

:slight_smile: Cheers Tom

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.

Hi ScallioXTX,

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 :smiley: ) 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 :slight_smile:

1 Like

Unfortunately, even with the “full” access it does not work :frowning:
Maybe it is better to completely delete it and set-up a new …

Or set up a local development environment where you can tune it until you know what goes where without any fear of messing up production.

Hi Scallio,


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 :slight_smile: BR Tom

I must say I find that very scary. Problems that disappear all on their own have a way of popping back up later.

Then again, maybe it really was a fluke and the problem stays gone. Let’s hope so.

@rpkamp and you are right, even after complete new installation, it appears again and along with that, no feeds are coming in. I give up now

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.