It turns out that CentOS-7 is also a synonym for SELinux. This has two adverse effects on the OLFS:
When utilizing the default configuration location: $CATALINA_HOME/webapps/opendap/WEB-INF/conf the OLFS is not able to create or write to the directory $CATALINA_HOME/webapps/opendap/WEB-INF/conf/logs
If the user creates the directory /etc/olfs and then uses the traditional methods to assign its ownership to the tomcat user and group ( chown tomcat:tomcat /etc/olfs ) the server fails to start because it is unable to copy it's configuration information to this location.
Both of these issues happen because SELinux blocks these write attempts. I think I see how to fix it: It appears that ls --lcontext is our friend here and the chcon command will do the dirty work. This page was super useful:
On the CentOS-7 system in question I see this:
And my assessment is that once we get the permissions on /etc/olfs to match the ones on /var/lib/tomcat/webapps it will probably work as desired. We might also reconsider the location /etc/olfs. Regardless, maybe I should work on the bootstrap code in the OLFS so that if it does detect that the target (/etc/olfs or otherwise) is not writable (or just readable? we should discuss) then it should log errors and then fall back to the default configuration bundled in the distribution so that it successfully starts. The rub here is that all of these errors are now captured by systemd and only accessible via journalctl -u tomcat and not in the expected catalina.out file which could mean that users will find it difficult to understand wtf is going on. Of course this logging change is beyond our control so if the OLFS fails to start (current situation) or starts with a long list of errors about configuration mishaps (proposed situation) the users are still stuck with trying to understand the situation.
More useful information might be contained here: https://blog.lysender.com/2015/07/centos-7-selinux-php-apache-cannot-writeaccess-file-no-matter-what/