Jira take hours to start with TB disk drives due to error Unable to attach or mount volume shared-home
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
Summary
Jira running in a K8s environment when the Pods are trying to mount the PersistentVolume (Jira Shared home) having a large number of files, kubelet will attempt to change ownership on each file on the filesystem, which can increase volume mount latency.
This will cause the Unable to attach or mount volume for pod; skipping pod ... timed out waiting for the condition error.
Cause
Using the Atlassian Official Helm Charts the securityContext is enabled by default. So each pod will attempt to change ownership on each file on the filesystem.
Here at the following sample values.yaml file, we can see the default configuration for the securityContext configuration.
values.yaml
1
2
3
4
5
6
7
8
9
10
11
12
# -- Whether to apply security context to pod.
#
securityContextEnabled: true
securityContext:
# -- The GID used by the Jira docker image
# GID will default to 2001 if not supplied and securityContextEnabled is set to true.
# This is intended to ensure that the shared-home volume is group-writeable by the GID used by the Jira container.
# However, this doesn't appear to work for NFS volumes due to a K8s bug: https://github.com/kubernetes/examples/issues/260
#
fsGroup: 2001Solution
As mentioned in this Troubleshooting storage in GKE document, to solve the performance issue, it is recommended to insert the fsGroupChangePolicy configuration to OnRootMismatch. This will make the command to only change files and directories that are not with the desired permissions.
values.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
# -- Whether to apply security context to pod.
#
securityContextEnabled: true
securityContext:
# -- The GID used by the Jira docker image
# GID will default to 2001 if not supplied and securityContextEnabled is set to true.
# This is intended to ensure that the shared-home volume is group-writeable by the GID used by the Jira container.
# However, this doesn't appear to work for NFS volumes due to a K8s bug: https://github.com/kubernetes/examples/issues/260
#
fsGroup: 2001
fsGroupChangePolicy: "OnRootMismatch"Was this helpful?