Permanent directory is ignored and data is in Tomcat work directory


I’ve installed on a hosted webserver (inmotionhosting, VPS hosting), which is running CentOS7.
Installed JDK1.8 and Tomcat 8.5, MySQL (MariaDB 10.2)

Downloaded XWiki 10.10 the latest stable, and installation is completed and I have modifed xwiki.cfg and to make sure DB is connected and permanent directory is set.

But however I make an effort to set the ‘environment.permanentDirectory’, the permanent directory is set to work directory under tomcat, and I have no idea why.

I tried changing several locations, and I even tried to set, but still works on work directory.

I’ve used this to check.


It always give me this directory:


where /opt/apache-tomcat-8.5.34 is tomcat installed directory.

This is current permanent directory setting:

~# environment.permanentDirectory=/var/local/xwiki/ - not working
~# environment.permanentDirectory=/usr/xwiki/ - not working

Where do I look after to set proper permanent directory?


can you paste the part of your file where you set the permanent dir?

You should take a look at your startup log, maybe whatever you set is not accessible for XWiki in which case it will fallback in the default one and you should see all that in the log.

The XWiki Debian package is using environment.permanentDirectory=/var/lib/xwiki/data and it works just fine but tomcat user need to have write access in this folder.

I’ve pasted on original:
to check if they change the folder… I’ve tried several other folders but they didn’t work.

Found the log and I got the clue.

ERROR o.x.e.i.ServletEnvironment - Configured permanent directory [/opt/tomcat/webapps/xwiki/data] is not writable.


I am also encountering this issue. Log shows

[main] ERROR o.x.e.i.ServletEnvironment     - Configured permanent directory [/var/lib/xwiki/data] is not writable.
[main] WARN  o.x.e.i.ServletEnvironment     - Falling back on [/var/cache/tomcat9/Catalina/localhost/xwiki] as the permanent directory.
[main] INFO  o.x.e.i.ServletEnvironment     - Using permanent directory [/var/cache/tomcat9/Catalina/localhost/xwiki]

I have verified the tomcat user has write access to the directory.

$ sudo -u tomcat touch tomcatfile
$ ls -la /var/lib/xwiki/data
total 8
drwxr-xr-x 2 tomcat tomcat 4096 Nov  6 15:47 .
drwxr-xr-x 4 root   root   4096 Nov  6 12:00 ..
-rw-r--r-- 1 tomcat tomcat    0 Nov  6 15:47 tomcatfile

Also tried chmod 777. No luck.

This is on Ubuntu 18.04LTS, so no SELinux.

I found the solution to this issue. In my case, it turns out that Debian packages Tomcat configured to be sandboxed, with write access only to certain directories, /var/lib/xwiki/data not being one of them. To solve, I had to create a systemd service override file to allow Tomcat to have write access to /var/lib/xwiki/data.

mkdir /etc/systemd/system/tomcat9.service.d/
echo -e "[Service]\nReadWritePaths=/var/lib/xwiki/data" > /etc/systemd/system/tomcat9.service.d/override.conf
systemctl daemon-reload
systemctl restart tomcat9.service

If you were already using XWiki and installed extensions and added attachments, you will need to move the data from the fallback directory to /var/lib/xwiki/data.

systemctl stop tomcat9.service
mv /var/cache/tomcat9/Catalina/localhost/xwiki/* /var/lib/xwiki/data/
systemctl start tomcat9.service

Hi @g3poandlsl I just noticed your message thanks to @GOhrner. Thanks for the debugging and the details. I’m very surprised this hasn’t been reported more and I’m pretty sure others have been using Tomcat 9 packages but maybe it was on other systems (but Ubuntu tend to keep Tomcat packages coming from Debian as is).

I noticed other similar problems with other web apps mentioning /etc/systemd/system/tomcat9.d folder instead of /etc/systemd/system/tomcat9.service.d (for example for the solr Debian package). Any idea what’s best ? Trying to find some official documentation about that since I’m not really a systemd expert.

OK I know why, it does work just fine with a new install… just not in the right data folder.

I created and hopefully fixed Loading....

It will probably fail in case this working fresh installation’s config gets “fixed” such that the actually configured data directory is suddenly used instead of the fallback!

If this isn’t considered in the fix, such installations will break and bugs may be pouring in then (in addition to annoying users). :frowning:

Problem is that I’m not sure it’s easy to deal with that use case from the package install script.

At least people will clearly notice it and can refer to or the release note.

Unfortunately, I also do not have a good idea. Some packages issue some information messages / even dialog boxes, depending on the configured debconf notification level.

Maybe this could be an idea to point out the issue? This would at least help in the cases where the upgrade does not happen unattended, and where debconf was not configured to suppress all but mandatory user interaction…

Yeah… I ran aptitude safe-upgrade on an Ubuntu VM with XWiki on it last Friday, which incidentally upgraded XWiki from 11.10.2 to 11.10.3, which broke my XWiki.
I quickly restored the VM from a recent backup and all was good again.
Researching the issue today I found this thread.
So now I understand what went wrong and how to fix things so it doesn’t happen again. :slight_smile: