Tomcat is not getting started: Permission denied

Question

I am getting below error when trying to start the tomcat using systemd service

systemd[1]: tomcat.service: Failed to execute command: Permission denied
systemd[1]: tomcat.service: Failed at step EXEC spawning /opt/tomcat/bin/startup.sh: Permission denied

Below is my tomcat.service configuration

[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target

[Service]
Type=forking

Environment=JAVA_HOME=/usr/lib/jvm/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID

User=tomcat
Group=tomcat

[Install]
WantedBy=multi-user.target

These are my permission on files in the bin directory

drwxrwx---. 2 tomcat tomcat   4096 Mar 22 05:56 .
drwx------. 9 tomcat tomcat    276 Mar 22 05:58 ..
-rw-r-----. 1 tomcat tomcat  35071 Mar 11 09:33 bootstrap.jar
-rw-r-----. 1 tomcat tomcat  15953 Mar 11 09:33 catalina.bat
-rwxr-x--x. 1 tomcat tomcat  23792 Mar 11 09:33 catalina.sh
-rw-r-----. 1 tomcat tomcat   1664 Mar 11 09:36 catalina-tasks.xml
-rw-r-----. 1 tomcat tomcat   2123 Mar 11 09:33 ciphers.bat
-rwxr-x--x. 1 tomcat tomcat   1997 Mar 11 09:33 ciphers.sh
-rw-r-----. 1 tomcat tomcat  25197 Mar 11 09:33 commons-daemon.jar
-rw-r-----. 1 tomcat tomcat 206895 Mar 11 09:33 commons-daemon-native.tar.gz
-rw-r-----. 1 tomcat tomcat   2040 Mar 11 09:33 configtest.bat
-rwxr-x--x. 1 tomcat tomcat   1922 Mar 11 09:33 configtest.sh
-rwxr-x--x. 1 tomcat tomcat   8675 Mar 11 09:33 daemon.sh
-rw-r-----. 1 tomcat tomcat   2091 Mar 11 09:33 digest.bat
-rwxr-x--x. 1 tomcat tomcat   1965 Mar 11 09:33 digest.sh
-rw-r-----. 1 tomcat tomcat   3606 Mar 11 09:33 makebase.bat
-rwxr-x--x. 1 tomcat tomcat   3382 Mar 11 09:33 makebase.sh
-rw-r-----. 1 tomcat tomcat   3460 Mar 11 09:33 setclasspath.bat
-rwxr-x--x. 1 tomcat tomcat   3708 Mar 11 09:33 setclasspath.sh
-rw-r-----. 1 tomcat tomcat   2020 Mar 11 09:33 shutdown.bat
-rwxr-x--x. 1 tomcat tomcat   1902 Mar 11 09:33 shutdown.sh
-rw-r-----. 1 tomcat tomcat   2022 Mar 11 09:33 startup.bat
-rwxr-x--x. 1 tomcat tomcat   1904 Mar 11 09:33 startup.sh
-rw-r-----. 1 tomcat tomcat  49372 Mar 11 09:33 tomcat-juli.jar
-rw-r-----. 1 tomcat tomcat 419428 Mar 11 09:33 tomcat-native.tar.gz
-rw-r-----. 1 tomcat tomcat   4574 Mar 11 09:33 tool-wrapper.bat

NOTE: I am able to start the tomcat using sudo ./startup.sh command by navigating to bin directory

Ware

are permissions for /opt disallowing tomcat? – Leporine

your . and .. seems weird, add rx to /opt and /opt/bin – Beckner

Answer 1

Can you check your /opt and /opt/bin permissions

Looks like

chmod a+rx /opt /opt/tomcat/ /opt/tomcat/bin

should help

Palpitate

Here is permission for /opt ls -l /opt total 0 drwxr-xr-x. 3 root root 21 Apr 23 12:55 eff.org drwx--x--x. 9 tomcat tomcat 276 Mar 22 05:58 tomcat and for /opt/tomcat/bin ls -l total 128 drwxrwx---. 2 tomcat tomcat 4096 Mar 22 05:56 bin – Ware

@ Orel tried above command but still the issue is same ... Permission denied – Ware

I have executed the above command but still it's not working . – Ware

Are you using SELinux ? – Beckner

@ Orel Yes i am using SELinux – Ware

Try disabbling selinux and then fix you selinux permission – Beckner

Thanks @Orel it worked after changing the permission. Appreciate your help. But i need to enable it ...any idea how to by pass this permission for tomcat and not for other. – Ware

@Palpitate Thank you. It helped me after a lot of trouble. – Laryngology

Answer 2

I suppose you followed one of the many copied online tutorials where the tomcat user is made with /opt/tomcat/ as its home directory by using something similar like:

sudo useradd -d /opt/tomcat -s /sbin/nologin tomcat

SELinux is preventing applications from being launched from a home directory, with a message like the following in /var/log/audit/audit.log

type=AVC msg=audit(1614250994.710:33614): avc:  denied  { execute } for  pid=60244 comm="(artup.sh)" name="startup.sh" dev="dm-3" ino=19000615 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0

I don't believe the tomcat user needs a home folder, so either remove it from an existing user with:

sudo usermod -d / tomcat

Or create your new user with the following instead:

sudo useradd -M -s /sbin/nologin tomcat

Reset the SELinux properties with the following afterwards:

sudo restorecon -rv /opt/tomcat

Neau

Answer 3

I encountered same problem and fix it by restorecon. I don't know if the reason why the problem happened is same as the original question but I think it depends on how to install tomcat.

In general, we download the tar.gz onto a temp directory and tar xzvf at the temp directory. Next, we move it to /opt or /usr/local. At that time, if we use mv, SELinux context is not changed then permission denied happens. But you can change it by restorecon. If we use cp -R, SELinux context is changed then permission denied does not happen.

Ardennes

Answer 4

In case someone follows the google links to get here, there were three problems in my case that prevented Tomcat 9 (installed from TAR file) from starting on a RHEL 8 system that has CIS recommended security lock-downs on it. I think the DoD STIGs are similar, but not sure. I had the exact same messages in the system journal that the OP did.

First, our security folks went overboard and added the "noexec" option to the mount that the Tomcat was on, which is a separate partition and LVM volume for both security and organizational reasons. I had to modify the mount by removing the "noexec" option in the "/etc/fstab" file, to whit:

Before:

/dev/mapper/vg01-mymount  /mymount  xfs  defaults,nodev,noexec 0 0

After:

/dev/mapper/vg01-mymount  /mymount  xfs  defaults,nodev 0 0

Second, I found they had installed the "fapolicyd" daemon, and that acts like an application allow-listing for execution and access to files. Instead of using the standard method of adding individual binaries to a list in "/etc/fapolicyd/fapolicyd.trust", or creating files in "/etc/fapolicyd/trust.d/" directory, I followed recommendations from this reply on a blog entry here:https://computingforgeeks.com/install-apache-tomcat-9-on-linux-rhel-centos/#comment-7841 . This is the coward's way out, by adding all policy permissions for the tomcat user to access the whole tomcat directory, and depending on file-level permissions to do the security from there:

allow perm=any uid=tomcat gid=tomcat : dir=/mymount/tomcat/

I'm not really sure this will pass scrutiny with any security policies where you work, but it gets the thing running. Individual rules for fapolicyd can be made to run specific files, certain MIME types, read-only on whole directories, etc. The major flaw I found is that the logging from the daemon is less than stellar (or non-existent in my case), and left me scratching my head for a couple days as to what was blocking Tomcat starting. Just knowing fapolicyd is installed is half the battle won.

Third, checking SELinux reports (aureport binary) showed that the systemd binary context of "init_t" did not have permission to execute files in the Tomcat dir because they had the wrong context ("default_t"). Here I only changed the context of the script files in /tomcat/bin/ to "initrc_exec_t", which also may be bad, but it worked without disabling SELinux or doing weird things like compile a new SELinux policy file that allowed that access (i.e. allow init_t to execute default_t files, which seems like it would be much worse). I used a similar command set to the below:

semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/startup.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/shutdown.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/catalina.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/setclasspath.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/setenv.sh
restorecon -rv /mymount/tomcat/

I don't know if it needed the last three (catalina.sh, setclasspath.sh, setenv.sh), but I added them to be sure. This fixed my issue with systemd.

Lotty

Answer 5

[For those looking to solve selinux issues with Tomcat startup/shutdown...]

We also struggled to get the systemd scripts running at startup and shutdown on RHEL9 & Tomcat 9.0.85 from tarball. Our problem was similar to the 3rd circumstance above posted by 'db_'. selinux is once again the guilty culprit. But, our fix is slightly different. We ran the CIS benchmark/hardening script on this system during build as well. We have not further investigated the source of this selinux behavior change but selinux does not prevent startup/shutdown running RHEL7/Tomcat 8.5 despite selinux context TYPE being same (default_t).

The fix was to use bin_t, initrc_exec_t did not work. I found this which had the final missing clue:

https://www.ibm.com/support/pages/not-able-execute-systemctl-start-lsfdservice-rhel9x-selinux-set-enforcing

We also seemed to have trouble with the context of the soft-link to the 9.0.85 dir. We fixed its context ( '-f l'; see below). In any case, with the caveat that this may or may not be correct, here is what we did to allow tomcat to start and stop normally incl. fixing the soft link:

semanage fcontext -f l -a -t bin_t '/tomcat1/apache-tomcat-9'

semanage fcontext -a -t bin_t '/tomcat1/apache-tomcat-9.0.85/bin'

semanage fcontext -a -t bin_t '/tomcat1/apache-tomcat-9.0.85/bin/(.*).sh'

restorecon -RFv /tomcat1

Adaadabel

Answer 6

disable selinux

reboot

start tomcat

works

Because the selinux forbids other ports such as 8080 which is the default port for tomcat

Trews

The answer you provided suggesting to disable SELinux to resolve this issue might work in some scenarios, but is not recommended as the best approach. Disabling SELinux entirely impacts security of the system. Issues like this should be solved through proper configuration rather than disabling security features. – Angioma