Jira server running as unexpected user after using Linux installer
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Symptoms
The JIRA Service is running as the incorrect, or undesirable user after installing JIRA from the binary installer.
The user
jira1
is running the JIRA process instead ofjira
.The JIRA process can not be started as the expected user, and exceptions mentioning
Permission denied
The following may be found in the atlassian-jira.log
:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2015-01-01 20:00:00,805 http-bio-2002-exec-01 ERROR captainplanet 1374x4807x2 1uqrzw9 192.168.0.1 /secure/AttachFile.jspa [jira.issue.managers.DefaultAttachmentManager] Could not save attachment to storage: com.atlassian.jira.issue.attachment.AttachmentWriteException: Could not save attachment data from stream.
com.atlassian.jira.issue.attachment.AttachmentWriteException: Could not save attachment data from stream.
at com.atlassian.jira.issue.attachment.DefaultAttachmentStore$2.call(DefaultAttachmentStore.java:133)
at com.atlassian.jira.issue.attachment.DefaultAttachmentStore$2.call(DefaultAttachmentStore.java:122)
at com.atlassian.util.concurrent.Executors$DefaultSubmitter$CallableRunner.run(Executors.java:62)
at com.atlassian.util.concurrent.LimitedExecutor$Runner.run(LimitedExecutor.java:93)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(Unknown Source)
at com.atlassian.core.util.FileUtils.copyFile(FileUtils.java:461)
at com.atlassian.jira.issue.attachment.DefaultAttachmentStore$2.call(DefaultAttachmentStore.java:128)
... 6 more
Cause
When the JIRA Binary Installer creates a new JIRA instance, if the jira
user already exists, a new user is created. This may be undesirable causing the wrong user to run JIRA. The JIRA Binary installer automatically creates users in a sequential format, for example, jira1
, jira2
, jira3.
There is an issue to track this behaviour: JRASERVER-27376 - JIRA Linux .bin installer creates multiple jira users after subsequent installs.
Resolution
You will need to decide what user should execute JIRA. In the steps below the username: jira
is being used.
Shutdown JIRA using either:
the service:
service <JIRA_SERVICE_NAME> stop
the command
<JIRA_INSTALL
>/bin/stop-jira.sh
Ensure you can log into your
jira
user account.Set
jira
to have correct ownership on your<JIRA_INSTALL
> and <JIRA_HOME> directories. One method to do this is to run the following command as a super-user:1 2
chown jira:jira -R <JIRA_INSTALL> chown jira:jira -R <JIRA_HOME>
Update the file
<JIRA_INSTALL>/bin/user.sh
so that the script references the correct user. For example, changejira1
in the file tojira
:1 2 3 4
# START INSTALLER MAGIC ! DO NOT EDIT ! JIRA_USER="jira1" ## # END INSTALLER MAGIC ! DO NOT EDIT ! export JIRA_USER
Start JIRA using either:
the service:
service
<JIRA_SERVICE_NAME>
start
the command
<JIRA_INSTALL
>/bin/start-jira.sh
To confirm the correct user is now being used to run JIRA, check the latest:
atlassian-jira.log
for the property:user.name
Was this helpful?