Issue Summary

When users upgrade Bitbucket by following this documentation and initiate the installation using the command sudo ./installer.bin while the service at /etc/init.d/atlbitbucket does not exist, ownership over both the $BITBUCKET_HOME and the installation directory will be set to root:root, despite a differing user or systemd service potentially being used to run Bitbucket. This then causes Bitbucket's startup to fail, as the non-root account used to run Bitbucket is unable to access the files in the home and install directories.

Steps to Reproduce

1. Configure Bitbucket to run using a systemd unit file, as described in this guide.
   • Do not create a service/file at /etc/init.d/atlbitbucket
2. Upgrade Bitbucket using the binary file with the command: sudo ./installer_name.bin.

Expected Results

The systemd service is detected, and the Bitbucket home and install directory are set to be owned by the service account for that service.

Actual Results

Since we only check for /etc/init.d/atlbitbucket, no service is detected, and the default behavior occurs of setting the home and install directories to be owned by the user running the installer (so in this case, root).

Workaround

When this occurs, an admin must manually correct the directory permissions by running a command such as the following before the application can be successfully started:

chown atlbitbucket:atlbitbucket /path/to/$BITBUCKET_HOME /path/to/$BITBUCKET_INSTALL -R

To prevent the issue moving forward, admins have the following options:

• Deploy any future updates through the tarball/archive instead of using the installer, ensuring the appropriate permissions are set for the extracted install directory.
• Create a dummy file/service at /etc/init.d/atlbitbucket so that the installer understands that Bitbucket is running under a service account, preventing it from changing ownership to the user running the installer.
• Run the installer without sudo and using the account that's being used to run Bitbucket.
• Include a step in future maintenance plans to preemptively run the above chown command after the installer finishes.

Notes

If contacting Atlassian Support with any issues related to the installer's behavior, it's recommended to provide a zip of the installer's logs that are located in the hidden .install4j directory within the $BITBUCKET_INSTALL directory.