@nmstoker opened this Issue on October 5th 2015


I believe the CentOS server I'm using is correctly set up for Piwik (eg got the necessary PHP and MySQL requirements etc etc). I unzipped the file from http://builds.piwik.org/piwik.zip just earlier today (05-Oct-2015) into a directory /piwik in /var/www/html/.

However when I go to the server's URL for piwik, I get the error message in the title:

The directory "/var/www/html/piwik/tmp/cache/tracker/" is not writable.

I've checked the error log (in /var/log/httpd/error_log) and it shows the same error message.

My immediate thought was that file ownership or permissions were wrong, so I set about fixing that - although initially there was no directory /cache/tracker within /tmp, so I created that. I did the following commands (after creating the tracker directory):

sudo chmod -R 0755 piwik/
sudo chown apache:apache -R piwik/

and restarted Apache, but to no avail.

I also set the tracker directory to 777 (not that I want to leave it that way) and that didn't make any difference. I also confirmed that Apache is indeed running with the user and group of "apache" (just in case there was something unexpected, but there wasn't).

What are the next steps to try? Or where else should I look for any more diagnostic information?

Many thanks,

@mattab commented on October 6th 2015 Member

What are the next steps to try? Or where else should I look for any more diagnostic information?

Give write permission to the piwik/tmp/ folder, recursively, should fix it.

We got this request several times in the forum, so we should detect when this occurs and display a friendly error message with the commands to type to fix it

@nmstoker commented on October 7th 2015

Thanks @mattab but I believe the command sudo chmod -R 0755 piwik/ would have already done that (since it's recursive and applied to the whole piwik directory structure, including /tmp).

Just to be sure though, I tried it purely on the /tmp directory structure recursively (-R) with 777 (just as a temporary measure, I'm aware of the long-term security concerns), which should give write permission to absolutely everyone and it still comes up, even after a restart of apache.

One other idea I had was regarding the particular directories (if any) which need to be in /tmp?

I got thinking along these lines because there were literally no other directories in there when I first installed (I had to create /cache/tracker) and I've seen certain other issues raised where the advice was to change permission settings on other directories in /tmp that I also do not have. See here: http://issues.piwik.org/6841 (it mentions tmp/assets/, tmp/tcpdf/ etc)

Is that a sensible thing to check? Anything else?

@tsteur commented on October 8th 2015 Member

Just to be sure: It should be the tmp directory within your Piwik installation, not /tmp. If there is no such directory in your tmp directory it had no permissions to create them. What does ls -al piwik/tmp and ls -al piwik | grep "tmp" output?

@nmstoker commented on October 8th 2015


Hi @tsteur - the output's shown (I had indeed applied the changes to the tmp directory within piwik, but it was a good thing to check).

I did confirm that the apache process is running as apache/apache for owner and group respectively (did this by checking in httpd.conf)

Do the details in the screenshot look okay?

@Blackpig commented on October 12th 2015

One of my client's is reporting the same issue. They had been logging with no problems now they get the same error as reported above.

I've loosened the permissions to 0777 and ensured the owner is apache:apache for piwik/tmp and all subdirectories. I can see files with in the directories, some of which have been written today.

I don't understand why we're getting a permissions error that's preventing the user's from logging in when everything was running fine previously. We've not upgraded from the initial installed version (2.14.3)

They're running a CentOS7 install and Piwik 2.14.3

@tsteur commented on October 13th 2015 Member

Did this error appear after updating to 2.14.3? Is it a standard CentOS?

Is it possible that we maybe get access to a server that is having this problem so we can debug? Or can you reproduce it on a standard CentOS installation?

@mattab maybe it's worth we try to install Piwik on a CentOS?

@Blackpig commented on October 13th 2015

Sorry, you can't have access to the server.

It wasn't an upgrade, it was a straight 2.14.3 install.

I have their sys admins looking at it the moment, if we identify the problem and find a solution I'll post back.

@nmstoker commented on October 13th 2015

My situation seems the same as @Blackpig - it was a straight install of 2.14.3 downloaded directly from http://piwik.org/download/ on 7th October (it's identical to the currently available zip file; and it was not an upgrade).

Our server is not publicly available either, but I'm able to check any details necessary. I'll see if I can get a standard CentOS installation set up at home to try to reproduce it (much as I'm keen to keep this moving forward, it'll most likely will be later in the week or over the weekend before I can do that).

@Blackpig commented on October 13th 2015

The sysadmins tracked it down to a setting in SELinux (which I understand is standard on CentOS).

They changed the following setting:

setsebool -P httpd_unified 1

TBH I don't what that boolean does but it may point you in the right direction in looking at SELinux booleans to fix the issue.

@tsteur commented on October 14th 2015 Member

I'm not really familiar with it either. Maybe someone else knows if it can be caused by this setting?

@kfiresmith commented on December 1st 2015

@Blackpig - thanks very much for taking the time to note the 'sesetbool' command to fix this. I can confirm this fixes the issue on RHEL 7.2.

@tsteur commented on December 1st 2015 Member

@mattab would this something be for a FAQ? Not writable directories on RHEL? Ideally we would detect a RedHat when showing this message and directly suggest this solution but probably happens to rarely maybe. Otherwise we can close it I reckon.

@kfiresmith commented on December 1st 2015

@tsteur - Actually after reading more about this SELinux boolean we are using for now as a "fix" for the problem, I don't think it's the right way to address the issue as it opens Apache very widely - more of a sledgehammer than a scalpel. Here's a blurb on the boolean:

"This Boolean is off by default, turning it on will allow all httpd
executables to have full access to all content labeled with a http file
context. Leaving it off makes sure that one httpd service can not
interfere with another." (https://www.redhat.com/archives/fedora-selinux-list/2009-March/msg00068.html)

This sounds bad from a security standpoint so it's probably not something that should be documented as the official way to overcome this issue.

Poking around a bit more I found this passage:
"httpd_unified basically says to SELinux allow Apache processes to treat all Apache content with the same rules. In RHEL7 we feel users are familiar enough with SELinux to disable the httpd_unified boolean by default. If this boolean is off, then users would have to label files/directories as httpd_sys_content_rw_t if they wanted Apache to be able to write to a directory rather then the read/only label of httpd_sys_content_t. With the boolean on, Apache processes can read/write/execute all httpd_sys_content* labels." (http://danwalsh.livejournal.com/56760.html)

So the proper fix here is probably to relabel the SELinux context of the currently unwritable folder like so:

ls -laZ /var/www/html/piwik/tmp/cache/

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 ..
drwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 tracker

chcon -R -t httpd_sys_content_rw_t tracker/

ls -laZ /var/www/html/piwik/tmp/cache/

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 ..
drwxrwxrwx. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 tracker

systemctl reload httpd.service

...granted this doesn't fix everything - it merely gets us past the 1st instance of this we come across which is mentioned in this issue. There are other places to overcome this the same way - I'll address those in the next comment.

@kfiresmith commented on December 1st 2015

After getting past the first SELinux write blocking issue mentioned in my last comment, you will end up looking at an error page that looks like this:

Piwik couldn't write to some directories (running as user 'apache').

Try to Execute the following commands on your server, to allow Write access on these directories:

chown -R apache:apache /var/www/html/piwik
chmod -R 0755 /var/www/html/piwik/tmp
chmod -R 0755 /var/www/html/piwik/tmp/cache

If this doesn't work, you can try to create the directories with your FTP software, and set the CHMOD to 0755 (or 0777 if 0755 is not enough). To do so with your FTP software, right click on the directories then click permissions.

...It provides good clues about what needs to be relabeled, but those notes above should probably be amended to include SELinux fixes as well:

ls -Z /var/www/html/piwik | grep tmp

drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 tmp

ls -Z /var/www/html/piwik/tmp/ | grep cache

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 cache

chcon -t httpd_sys_content_rw_t /var/www/html/piwik/tmp

chcon -R -t httpd_sys_content_rw_t /var/www/html/piwik/tmp/cache

ls -Z /var/www/html/piwik | grep tmp

drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 tmp

ls -Z /var/www/html/piwik/tmp/ | grep cache

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 cache

systemctl reload httpd.service

I have confirmed that the above steps gets the ball rolling on the installation once more.

So in conclusion I recommend please not documenting that SELinux boolean - it's punching a very large security hole where we only need a tiny one.

@tsteur commented on December 1st 2015 Member

Thx for this detailed answer and good to know we shouldn't document the setbool. I'm not much familiar with SELinux / Red Hat so really appreciated. So from what I understand the thing that does the trick is eg chcon -R -t httpd_sys_content_rw_t /var/www/html/piwik/tmp/cache followed by systemctl reload httpd.service? This might also have to be done for other directories as you already mentioned

@kfiresmith commented on December 1st 2015

@tsteur -
I was able to summarize this a bit more clearly (by dropping the rationale for it...) in this comment:


I think the FAQ update, if you decide to do one, should have the fix foremost, with maybe a small blurb afterward to note it's an SELinux thing and this is how you can cleanly fix it rather than resorting to making global changes in how SELinux is protecting the web server.

@nmstoker commented on December 1st 2015

@kfiresmith - great work. I hadn't got round to testing the boolean "fix" yet, but your point about it being overly broad had concerned me. Many thanks for sharing the more focused solution, I'll give it a go soon.

@tsteur commented on December 1st 2015 Member

Thx a lot @kfiresmith . We should definitely put this in a FAQ since many people seem to have this issue @mattab Ideally we would maybe even directly detect SELinux and suggest solution in the UI

@kfiresmith commented on December 1st 2015

2 more minor tweaks (I'm kind of walking the install along as far as I can w/o actually changing anything since I'm the Linux sysadmin and not the web guy who is in charge of the app...)

This also needs done:

chcon -R -t httpd_sys_content_rw_t /var/www/html/piwik/config

And the Apache reloads I injected into the process aren't actually needed; the change is effective immediately.

@kfiresmith commented on December 2nd 2015

Moving along to the MySQL connection part of the configuration - you'll need to also set this SELinux boolean:

setsebool -P httpd_can_network_connect_db 1

@kfiresmith commented on December 4th 2015

A more SELinux-knowledgeable admin at my infra brought up that we should be using 'semanage fcontext' in place of 'chcon' so that the changes are more persistent. The prior 'chcon' commands I gave will survive updates and reboots, but if someone kicks off a 'restorecon' job on the paths or partitions where piwik lives, then our 'chcon'-based changes will all be reverted.

Here is the 'semanage fcontext' guidance page for RHEL 6 (which will be identical for EL7, and CentOS/Fedora releases):


So the documentation should go a little something like this:
"semanage fcontext -a -t httpd_sys_rw_content_t {dirs}" with {dirs} being:


...then of course still set the boolean mentioned earlier:
setsebool -P httpd_can_network_connect_db 1

EDIT: Fixed typo originally posted in this comment ( httpd_sys_content_rw_t should have been httpd_sys_rw_content_t)

PS: For the curious, I figured out the context typo via looking through the known file types and policy associations with various paths like so:

semanage fcontext -l | grep httpd | grep rw

/etc/glpi(/._)? all files system_u:object_r:httpd_sys_rw_contentt:s0
)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/drupal.* all files system_u:object_r:httpd_sys_rw_contentt:s0
)? all files system_u:object_r:httpd_sys_rw_contentt:s0
)? all files system_u:object_r:httpd_sys_rw_contentt:s0
)? all files system_u:object_r:httpd_sys_rw_contentt:s0
)? all files system_u:object_r:httpd_sys_rw_contentt:s0
)?/uploads(/._)? all files system_u:object_r:httpd_sys_rw_contentt:s0
)?/wp-content(/._)? all files system_u:object_r:httpd_sys_rw_content_t:s0

Hope this helps others in the future!

@7starsone commented on December 22nd 2015

I have another kind of issue here.. I'm using FCGId and changed the DocumentRoot from /home/myuser/www to _/home/myuser_
it still tries to write on the old /home/myuser/_www_/piwik...

_HP Fatal error: Uncaught exception 'InvalidArgumentException' with message 'The directory "/home/myuser/www/piwik//tmp/cache/tracker/" is not writable.' in /home/myuser/www/piwik/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FileCache.php:89_

why and how to fix? Do I need to delete the old directory and why? Or the error is anywhere else?
Thank you

@mattab commented on December 23rd 2015 Member


  • what does uname -a return for you? I'm wondering how to test whether SELinux is used.
  • as you suggested (source), we could add the following instructions for SELinux users:
chcon -t httpd_sys_content_rw_t /var/www/html/piwik/tmp
chcon -R -t httpd_sys_content_rw_t /var/www/html/piwiki/tmp/tracker/
chcon -R -t httpd_sys_content_rw_t /var/www/html/piwik/tmp/cache
systemctl reload httpd.service
@krisbai commented on January 6th 2016

sorry ,

@thyat000 commented on February 24th 2016

I am trying to install piwil on Linux 3.10.0-229.20.1.el7.x86_64 and encounter this issue. The directory "/var/www/html/piwik/tmp/cache/tracker/" is not writable. Apache is started as root, not apache user. Do I have to start Apache as apache user? It does not work for me.

Please advise,

@ClaudiuC commented on February 26th 2016

Got the same error on an HHVM machine. I created the directory (only piwik/tmp was there) and then ran sudo chown www-data:www-data -R piwik/ - all good now

@thyat000 commented on February 26th 2016

I ran chown -R apache:apache /var/www/html/piwik/tmp/* and it works for me ,too.


@pizzarabe commented on March 24th 2016

I relabeled my /var/www/html/piwik/tmp directory and the config.ini.php to httpd_sys_rw_content_t (to allow write from nginx/apache). I also allowed my mysqld to read, getattr and open files with the httpd_sys_rw_content_t context to get the "LOAD DATA INFILE" ability working.

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/piwik/tmp(/.*)?
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/piwik/config/config.ini.php"
restorecon -Rv /var/www/html/piwik/

Content of my selinux_module:

module allow_mysqld_getattr_httpd_sys_rw_content 1.3;

require {
    type mysqld_t;
    type httpd_sys_rw_content_t;
    class file { read getattr open }; 

allow mysqld_t httpd_sys_rw_content_t : file { read getattr open };

checkmodule -M -m -o allow_mysqld_getattr_httpd_sys_rw_content.mod allow_mysqld_getattr_httpd_sys_rw_content.te

semodule_package -o allow_mysqld_getattr_httpd_sys_rw_content.pp -m allow_mysqld_getattr_httpd_sys_rw_content.mod

semodule -i allow_mysqld_getattr_httpd_sys_rw_content.pp

I also needed to allow my httpd_t (using php-fpm) to connect to my msqld socket:

setsebool -P httpd_can_network_connect_db=1

I still get some SElinux denies but Piwik is working pretty well.

The only other denial i got was the access to the /var/www/html/piwik/misc/user/index.html.
If you want a "custom logo for this Piwik server", you should set the context for /var/www/html/piwik/misc/user/* to httpd_sys_rw_content_t as well.

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/piwik/misc/user(/.*)?
restorecon -Rv /var/www/html/piwik/misc/user

_Edit2 _

Maybe a Module is a SELinux Overkill...You need that only if you want to install piwik.

@NealWalters commented on November 23rd 2017

I have only CPanel hosting. Has been working fine for about 3 months, then suddenly stopped today.
I've done chmod 755 on all directories, but still getting error. What else can I do? Here is a screen shot of my server info: https://imgur.com/a/Yna6i


@mattab commented on July 8th 2019 Member

Thank you all for the feedback and steps!

-> a new FAQ was published to hopefully summarise the solutions: How do I fix the errors “Unable to write in the cache directory” or “The directory matomo/tmp/cache/*” is not writable.”?. Any feedback/suggestion about the content is always welcome!

will mark this issue as closed for now but if you still experience the issue, or have any suggestion, please re-open this or create a new one.

This Issue was closed on July 8th 2019
Powered by GitHub Issue Mirror