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

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?

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?

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?

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

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?

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.

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).

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.

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

@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.

@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.

@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.

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.

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

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

#9317 (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.

@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.

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

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.

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

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

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html

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

/var/www/html/piwik/tmp
/var/www/html/piwiki/tmp/tracker
/var/www/html/piwik/tmp/cache
/var/www/html/piwik/config

...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_content_t:s0
/etc/horde(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/drupal.* all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/z-push(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/lib/svn(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/svn(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/etc/owncloud(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.)?/uploads(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.)?/wp-content(/.)? all files system_u:object_r:httpd_sys_rw_content_t:s0

Hope this helps others in the future!

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

@kfiresmith

• 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

sorry ，

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,

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

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

Thanks,

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.

Edit:
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.

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

Thanks,
Neal

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.