• 7
    • 6
    • Severity 3 - Minor
    • 0
    • Hide
      Atlassian Update – 23 October 2018

      Hi everyone,

      We have recently reviewed this issue and the overall interest in the problem. Since the issue hasn't collected votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future, i.e. in next 6 months.

      Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Jira team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Atlassian Bugfix Policy for more details.

      We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication.

      Atlassian will keep the issue open and continue to watch this issue for the further updates.

      Thank you,
      Ignat Alexeyenko
      Jira Bugmaster

      Show
      Atlassian Update – 23 October 2018 Hi everyone, We have recently reviewed this issue and the overall interest in the problem. Since the issue hasn't collected votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future, i.e. in next 6 months. Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Jira team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Atlassian Bugfix Policy for more details. We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will keep the issue open and continue to watch this issue for the further updates. Thank you, Ignat Alexeyenko Jira Bugmaster

      Steps to Replicate

      1. Download JIRA 7.0.2 Software Linux installer
      2. Run it with Root user
      3. Finish the Installation.

      Expected Behavior

      JIRA's folders would have the correct permissions for user 'jira' and all files would be created without any issues.

      Actual Behavior

      Jira's folders that are owned by the "jira" user don't have the write permission.
      Upon JIRA start, the following error appears in catalina.out:

      SEVERE: Unable to create directory for deployment: /opt/atlassian/jira/conf/Catalina/localhost
      

      And the directory above fails to be created.
      Note: If the installer is ran by another user, all JIRA folders will have their permissions attached to only the user who ran the command, therefore the issue does not reproduce.

      Workaround:

            [JRASERVER-47727] JIRA 7.0.2 permission issues when installing as Root

            Okay, finally found a workaround. Here's what I've learned:

            1. Somewhere in the middle of trying to triage this, I'd screwed up my response file. This is the only reason that the service wasn't being created. Today, I fixed the response file and the service is being created now. (It still can't be started, but that's separate.)
            2. After the installer has finished running, it leaves the JIRA process behind in a way that will prevent you from even trying to restart the service. Run
              $ sudo pkill -u JIRA java

              to fix this problem. That's step #1 of the needed workaround.

            3. Once you've killed the dangling process, create the needed missing directories and reassign their ownership correctly:
              $ sudo mkdir -p /opt/atlassian/jira/conf/Catalina/localhost
              $ sudo chown -R jira:jira /opt/atlassian/jira/conf/Catalina

              That's step #2 of the needed workaround.

            4. Restart the service. Things should be working now. Yay!

            I still have no clue why this is needed on Ubuntu 16.04, but isn't on Ubuntu 14.04. But at least there's a usable workaround.

            Karl M. Davis added a comment - Okay, finally found a workaround. Here's what I've learned: Somewhere in the middle of trying to triage this, I'd screwed up my response file. This is the only reason that the service wasn't being created. Today, I fixed the response file and the service is being created now. (It still can't be started, but that's separate.) After the installer has finished running, it leaves the JIRA process behind in a way that will prevent you from even trying to restart the service. Run $ sudo pkill -u JIRA java to fix this problem. That's step #1 of the needed workaround. Once you've killed the dangling process, create the needed missing directories and reassign their ownership correctly: $ sudo mkdir -p /opt/atlassian/jira/conf/Catalina/localhost $ sudo chown -R jira:jira /opt/atlassian/jira/conf/Catalina That's step #2 of the needed workaround. Restart the service. Things should be working now. Yay! I still have no clue why this is needed on Ubuntu 16.04, but isn't on Ubuntu 14.04. But at least there's a usable workaround.

            Karl M. Davis added a comment - - edited

            Ran into this myself today and have some useful information that I can add to the bug:

            • I automated the installation of JIRA 7.1.4 using Ansible last year. This gives me a script I can run at any time to stand up a new JIRA server in EC2 and install JIRA on it.
            • I've been running that script all week, as I was tweaking other servers it manages, and it's been working fine.
            • Today, however, I switched the JIRA box that the script creates to Ubuntu 16.04 (Xenial), from the Ubuntu 14.04 (Trusty) that it had been using.
              • As soon as I made that switch (and only that switch), JIRA began failing to install correctly. The catalina.out file has the "Unable to create directory..." error in it, the JIRA service never gets created, and things just generally don't work.
              • The JIRA installer is already run as root, and MUST be, in order to create the JIRA service. The installation docs all agree on this (as noted by previous commenters here, above).
              • If I try to workaround the problem by first creating a "jira" user & group and then creating the needed directories with the correct permissions, the installer instead creates and uses a "jira1" user. Grrr!

            Due to this bug, there does not appear to be any way to install JIRA on Ubuntu 16.04 right now. I'll continue trying to find a workaround, but suspect I'll have to stick with Ubuntu 14.04 for the time being.

            Karl M. Davis added a comment - - edited Ran into this myself today and have some useful information that I can add to the bug: I automated the installation of JIRA 7.1.4 using Ansible last year. This gives me a script I can run at any time to stand up a new JIRA server in EC2 and install JIRA on it. I've been running that script all week, as I was tweaking other servers it manages, and it's been working fine. Today, however, I switched the JIRA box that the script creates to Ubuntu 16.04 (Xenial), from the Ubuntu 14.04 (Trusty) that it had been using. As soon as I made that switch (and only that switch), JIRA began failing to install correctly. The catalina.out file has the "Unable to create directory..." error in it, the JIRA service never gets created, and things just generally don't work. The JIRA installer is already run as root, and MUST be, in order to create the JIRA service. The installation docs all agree on this (as noted by previous commenters here, above). If I try to workaround the problem by first creating a "jira" user & group and then creating the needed directories with the correct permissions, the installer instead creates and uses a "jira1" user. Grrr! Due to this bug, there does not appear to be any way to install JIRA on Ubuntu 16.04 right now. I'll continue trying to find a workaround, but suspect I'll have to stick with Ubuntu 14.04 for the time being.

            I run into this again today as I was upgrading jira.

            While this seems to be a minor issue, I'd say it affects almost 100% of the installations, since like Philip says, the documentation appears to recommend installing as root.

            From the status of the issue, it seems that it's not a matter of the documentation being inaccurate but more of a small bug in the installers.

            Hopefully this will get fixed next time I do the upgrade round.

            Thanks!

            Agustin Martin added a comment - I run into this again today as I was upgrading jira. While this seems to be a minor issue, I'd say it affects almost 100% of the installations, since like Philip says, the documentation appears to recommend installing as root. From the status of the issue, it seems that it's not a matter of the documentation being inaccurate but more of a small bug in the installers. Hopefully this will get fixed next time I do the upgrade round. Thanks!

            PhilipJ added a comment -

            Thanks Os

            PhilipJ added a comment - Thanks Os

            Thanks phil59,

            I have reopened this to be investigated by the team who worked on the 7.0.0 installers to confirm whether the docs need to be updated and confirm whether my understanding of the installation process for Linux is correct or not.

            Cheers,
            Os.

            Oswaldo Hernandez (Inactive) added a comment - - edited Thanks phil59 , I have reopened this to be investigated by the team who worked on the 7.0.0 installers to confirm whether the docs need to be updated and confirm whether my understanding of the installation process for Linux is correct or not. Cheers, Os.

            PhilipJ added a comment - - edited

            Hi Os,

            If this is a true resolution, then I think you need to update the documentation here:
            https://confluence.atlassian.com/adminjiraserver070/installing-jira-applications-on-linux-749382634.html

            If you execute the Linux installer with 'root' user privileges, the installer will create and run JIRA using a dedicated user account. You can also execute the Linux installer without 'root' user privileges, although your installation options will be much more limited, and a dedicated user account (to run JIRA) will not be created. To run JIRA as a service, the Linux installer must be executed with 'root' user privileges.

            As I read this, it encourages the use of the root account to install since:

            1. you get more installation options
            2. you can run JIRA as a service

            Can you have the documentation updated to reflect your comment "You should install JIRA with the user that is meant to own and run the service." - or perhaps the resolution to this case is not correct?

            Also, why was this issue considered important to fix in 6.2 (JRA-38840), but is now not considered an issue when it has regressed?

            PhilipJ added a comment - - edited Hi Os, If this is a true resolution, then I think you need to update the documentation here: https://confluence.atlassian.com/adminjiraserver070/installing-jira-applications-on-linux-749382634.html If you execute the Linux installer with 'root' user privileges, the installer will create and run JIRA using a dedicated user account. You can also execute the Linux installer without 'root' user privileges, although your installation options will be much more limited, and a dedicated user account (to run JIRA) will not be created. To run JIRA as a service, the Linux installer must be executed with 'root' user privileges. As I read this, it encourages the use of the root account to install since: you get more installation options you can run JIRA as a service Can you have the documentation updated to reflect your comment "You should install JIRA with the user that is meant to own and run the service." - or perhaps the resolution to this case is not correct? Also, why was this issue considered important to fix in 6.2 ( JRA-38840 ), but is now not considered an issue when it has regressed?

            Hi mmuthusamy,

            This is by design. You should install JIRA with the user that is meant to own and run the service.

            Cheers,
            Os.

            Oswaldo Hernandez (Inactive) added a comment - Hi mmuthusamy , This is by design. You should install JIRA with the user that is meant to own and run the service. Cheers, Os.

              Unassigned Unassigned
              mmuthusamy Moga
              Affected customers:
              5 This affects my team
              Watchers:
              10 Start watching this issue

                Created:
                Updated: