Today I set out to deploy a triplestore on the server for Peculiar Parity. This should not have been a big deal. My initial choice was Fuseki, simply because I have not used it before and was curious to experiment with it. I installed Tomcat 9 using apt and copied the Fuseki war file into the default Tomcat webapps folder. Job done! Or not…
Fuseki threw an exception on startup. It was not able to access the /
etc/fuseki folder. No problem! I hadn’t realised that Fuseki required that this folder existed. Create the folder, give permissions to the
tomcat user and, job done! Or not…
Weird! What if I were to try something heinous and set the permissions on the
/etc/fuseki folder to 777? Job done? Nope!
OK, let’s try something else. I downloaded RDF4J, copied its war files over to the webapps folder, created the expected directories (which I placed in
/var/rdf4j-server to suit my own preferences) and job done? Still no…
The problem, as it turned out, lay with systemd, which apparently sandboxes Tomcat on Debian. This means that Tomcat and its respective apps can only modify folders if they sit within certain paths on the hard drive. Even if folder permissions give Tomcat the right to access and modify locations outside these paths, systemd blocks Tomcat’s access. Curious, but understandable from a security perspective.
The TLDR that will give you a solution is fairly simple. You just need to override systemd’s permissions on the folders that Tomcat apps need to access as documented in this StackOverflow post and in the Debian Java maintainer’s README. You can do this by creating a file
/etc/systemd/system/tomcat9.service.d/override.conf and add the following to it:
Of course, if overriding parameters put in place by systemd for the explicit purpose of protecting your server does not sit well with you, hopefully you can simply configure the app to write to a location where it has permission to perform edits. At the very least, this is achievable with Fuseki and RDF4J.