Ken - ah!

Thanks for the information.

    Andy

On 19/06/2020 22:48, Kenneth Keefe wrote:
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]



Reply via email to