One thing I quickly figured out was that the data directory previously belonged to the tomcat8 user, but now has to be owned by the tomcat user (without any version indicator).
This still does not help, though, Xwiki spits out tons of Solr errors due to attachments which cannot be found and just presents a white page during login.
Before I post logs indicating that I missed the most basic adjustments, I’ll try it differently: Is switching from Tomcat8 to Tomcat9 a supported upgrade path (and if not, what should I do?) and if so, what are the basic requirements and upgrade steps I need to perform?
Ok, obvious that this didn’t work - my xwiki data directory is somewhere else.
(BTW, why does the syntax chown -R tomcat.tomcat ... work - I didn’t know it and the manpage only seems to document : instead of . to separate username from group. Your syntax also seems to work, though.)
On a second look, Xwiki also still is not happy after I chowned the directory (the need of which was obvious from the first log messages of Xwiki).
It still logs
[2019-12-31 16:05:49] [info] 2019-12-31 16:05:49,263 [main] ERROR o.x.e.i.ServletEnvironment - Configured permanent directory [/mnt/cstore/var_lib_xwiki/data] is not writable.
[2019-12-31 16:05:49] [info] 2019-12-31 16:05:49,264 [main] WARN o.x.e.i.ServletEnvironment - Falling back on [/var/cache/tomcat9/Catalina/localhost/xwiki] as the permanent directory.
[2019-12-31 16:05:49] [info] 2019-12-31 16:05:49,265 [main] INFO o.x.e.i.ServletEnvironment - Using permanent directory [/var/cache/tomcat9/Catalina/localhost/xwiki]
Then it’s also clear that Solr cannot find anything meaningful there.
You are right, that’s the syntax I have been using for the last 15 years but the man page does not mention it indeed (at least on Ubuntu 19.10). Maybe it’s some deprecated syntax. I will check a few other systems and change it.
FirsI’m pretty sure the Tomcat 9 based package have been working just fine recently so maybe it’s specific to Debian Buster (but even that I think someone reported using Tomcat 9 package on Buster).
Would be great if you could create an issue on Loading... with everything related to can think of. If it’s the default now we’ll have to do something about it I guess.
Does your fix consider the case that someone successfully made a fresh install of Xwiki with Tomcat9, not even noticing that Xwiki fell back to using the Tomcat cache directory as its “permanent” directory?
If your fix just allows Xwiki to write to the actually configured permanent directory, all files stored so far in such installations will be “lost”. (Actually they probably still will reside in the cache directory, but the user will not know about it and will have no idea she/he even has to look for the files somewhere else!)
Is it really a good idea to fall back to another directory if the configured one is not writeable for some reason, or wouldn’t it be better to make this a critical failure and refuse to start Xwiki at all in this case? Then the user at least notices that something unexpected is going on…
