Ok! I've worked out the problem. I ended up creating a test web app that also wasn't able to write to the path. So, it wasn't a Fuseki issue. I finally found this email thread that solved it for me: http://tomcat.10.x6.nabble.com/migrate-to-tomcat-9-application-can-not-write-files-on-system-filder-td5087140.html
If you are running Tomcat 9 on Ubuntu 20.04, Tomcat is sandboxed by systemd and only has write access to some directories under /var/lib/tomcat. For more details, check out: https://salsa.debian.org/java-team/tomcat9/blob/master/debian/README.Debian To fix the specific issue of Fuseki not being able to write to its default path /etc/fuseki, you need to add a config file granting Tomcat permissions to write somewhere else. 1. Create a file located at /etc/systemd/system/tomcat9.service.d/override.conf 2. Write this in the new file: [Service] > ReadWritePaths=/etc/fuseki 3. Enter the following commands to flush the changes: systemctl daemon-reload > systemctl restart tomcat9 Now Fuseki should be able to load and write to that path, ASSUMING the filesystem permissions are already set up for the tomcat user. Thanks for the help everyone! Ken On Fri, Jun 19, 2020 at 9:29 AM Kenneth Keefe <[email protected]> wrote: > The user is tomcat. I checked the process listing to make sure that was > the user running tomcat. I also changed the permissions to 777 > temporarily just in case that was the problem. I'm at a loss for what could > be the problem. My next step is going to be to try and write my own web app > to test writing to that directory. > > Ken > > On Fri, Jun 19, 2020 at 2:57 AM Andy Seaborne <[email protected]> wrote: > >> Weird. That looks right >> >> What's the user for process for the tomcat process? >> >> At least for me, the user/group is "tomcat8" for a default installation >> of Tomcat and the tomcat java process runs with that user. >> >> Andy >> >> On 19/06/2020 08:06, Kenneth Keefe wrote: >> > I should have mentioned that I have openjdk 11.0.7 installed on this >> > machine. I'm not sure if that makes a difference in this situation. >> > >> > I don't think I have ACL set since I had to install acl to get the >> getfacl >> > command. However, here is what it reports for the directory: >> > >> > $ getfacl /srv/etc/fuseki >> > >> > getfacl: Removing leading '/' from absolute path names >> > >> > # file: srv/etc/fuseki >> > >> > # owner: tomcat >> > >> > # group: tomcat >> > >> > user::rwx >> > >> > group::rwx >> > >> > other::--- >> > >> > >> > $ getfacl /srv/etc >> > >> > getfacl: Removing leading '/' from absolute path names >> > >> > # file: srv/etc >> > >> > # owner: root >> > >> > # group: root >> > >> > user::rwx >> > >> > group::r-x >> > >> > other::r-x >> > >> > >> > $ getfacl /srv >> > >> > getfacl: Removing leading '/' from absolute path names >> > >> > # file: srv >> > >> > # owner: root >> > >> > # group: root >> > >> > user::rwx >> > >> > group::r-x >> > >> > other::r-x >> > >> > On Fri, Jun 19, 2020 at 12:51 AM Bruno P. Kinoshita <[email protected]> >> > wrote: >> > >> >> Hi Kenneth, >> >> >> >> >> >> I was going to suggest looking at chmod or chown and permissions for >> that >> >> folder, but looks like you've done that already. >> >> >> >> >> >> I'm on Ubuntu 18.04, but running from my user home directory. In case >> you >> >> are running out of ideas, maybe you can try some of these and see if it >> >> helps: >> >> >> >> >> >> - could it be that you have ACL set for that directory or one of its >> >> parents? (see getfacl) >> >> >> >> - not likely to have selinux as you are on Ubuntu, so maybe apparmor is >> >> set up and could be interfering? >> >> >> >> - any extra logs under /var/log/syslog or /var/log/auth.log? >> >> >> >> - could it be that one of the parent directories has a more restrictive >> >> permission? >> >> >> >> >> >> Hope that helps >> >> >> >> Bruno >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Friday, 19 June 2020, 4:37:59 pm NZST, Kenneth Keefe < >> >> [email protected]> wrote: >> >> >> >> >> >> >> >> >> >> >> >> I'm trying to set Fuseki up on a Ubuntu 20.04 box. I'm running Tomcat >> >> 9.0.31. I want to set the FUSEKI_BASE to /srv/etc/fuseki. In order to >> >> accomplish that, I created the file /usr/share/tomcat9/bin/setenv.sh >> that >> >> contains this: >> >> >> >> #!/bin/sh >> >>> export FUSEKI_BASE="/srv/etc/fuseki" >> >> >> >> >> >> When I deploy the 3.15.0 fuseki.war on tomcat, I get the following >> >> exception: >> >> >> >> 19-Jun-2020 04:23:37.533 SEVERE [main] >> >> org.apache.catalina.core.StandardContext.listenerStart Exception >> sending >> >> context initialized event to listener instance of class >> >> [org.apache.jena.fuseki.webapp.ShiroEnvironmentLoader] >> >> >> >> org.apache.jena.fuseki.FusekiConfigException: FUSEKI_BASE is not >> writable: >> >> /srv/etc/fuseki >> >> >> >> at >> >> >> >> >> org.apache.jena.fuseki.webapp.FusekiWebapp.formatBaseArea(FusekiWebapp.java:139) >> >> >> >> at >> >> >> >> >> org.apache.jena.fuseki.webapp.ShiroEnvironmentLoader.contextInitialized(ShiroEnvironmentLoader.java:50) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4685) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5146) >> >> >> >> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) >> >> >> >> at >> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) >> >> >> >> at >> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) >> >> >> >> at >> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:978) >> >> >> >> at >> >> >> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1849) >> >> >> >> at >> >> >> >> >> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) >> >> >> >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> >> >> >> at >> >> >> >> >> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) >> >> >> >> at >> >> >> >> >> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) >> >> >> >> at >> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:773) >> >> >> >> at >> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427) >> >> >> >> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576) >> >> >> >> at >> >> >> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) >> >> >> >> at >> >> >> >> >> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) >> >> >> >> at >> >> >> >> >> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) >> >> >> >> at >> org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) >> >> >> >> at >> >> >> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) >> >> >> >> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) >> >> >> >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> >> >> >> at >> >> >> >> >> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) >> >> >> >> at >> >> >> >> >> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) >> >> >> >> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) >> >> >> >> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> >> >> >> at >> >> >> >> >> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) >> >> >> >> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> >> >> >> at org.apache.catalina.startup.Catalina.start(Catalina.java:633) >> >> >> >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> >> Method) >> >> >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> >> >> at >> >> >> >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> >> >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> >> >> >> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) >> >> >> >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478) >> >> >> >> >> >> I have checked the permissions on the file system. /srv and /srv/etc >> are >> >> both 775. I changed ownership of /srv/etc/fuseki to the tomcat user and >> >> group and still get the exception. I tried changing permissions for >> both >> >> /srv/etc and /srv/etc/fuseki to 777 to see if it is running as a >> different >> >> user somehow. I still get the exception. >> >> >> >> What is the deal? What is causing this exception? >> >> >> >> I tried to look up the code that is throwing the exception and it looks >> >> like it is coming from this block of code: >> >> >> >> if ( Files.exists(FUSEKI_BASE) ) { >> >> if ( ! Files.isDirectory(FUSEKI_BASE) ) >> >> throw new FusekiConfigException("FUSEKI_BASE is not a >> directory: >> >> "+FUSEKI_BASE) ; >> >> if ( ! Files.isWritable(FUSEKI_BASE) ) >> >> throw new FusekiConfigException("FUSEKI_BASE is not writable: >> >> "+FUSEKI_BASE) ; >> >> } else { >> >> ensureDir(FUSEKI_BASE); >> >> } >> >> >> >> I don't understand how a Files.isWritable() call is failing with the >> file >> >> permissions set the way they are. >> >> >> >> Ideas? >> >> >> >> Ken >> >> >> > >> > >> > > > -- > ------- > Ken Keefe > Senior Software Engineer > Information Trust Institute > University of Illinois at Urbana-Champaign > 1308 W. Main St. > CSL 225 > Urbana, Illinois 61801, USA > Phone: 217-244-3203 > Web: https://www.perform.illinois.edu/~kjkeefe > Email: [email protected] > > -- ------- Ken Keefe Senior Software Engineer Information Trust Institute University of Illinois at Urbana-Champaign 1308 W. Main St. CSL 225 Urbana, Illinois 61801, USA Phone: 217-244-3203 Web: https://www.perform.illinois.edu/~kjkeefe Email: [email protected]
