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 xwiki.properties 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 xwiki.data.dir, but still works on work 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
environment.permanentDirectory=/opt/tomcat/webapps/xwiki/data
Where do I look after to set proper permanent directory?
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:
environment.permanentDirectory=/opt/tomcat/webapps/xwiki/data
to check if they change the folder… I’ve tried several other folders but they didn’t work.
[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
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/datanot 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.
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.
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.
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).
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.