Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article discusses how to fix issues that occur on a Microsoft Azure Kubernetes Service (AKS) cluster when you try to set the mounting options for user identifier (uid
) and group identifier (gid
) on an Azure disk.
Symptoms
If you try to set uid
and gid
to 1000 in the mountOptions
setting of the Azure disk's storage class configuration, you receive an error that resembles the following text:
Warning FailedMount 63s kubelet, aks-nodepool1-29460110-0 MountVolume.MountDevice failed for volume "pvc-d783d0e4-85a1-11e9-8a90-369885447933" : azureDisk - mountDevice:FormatAndMount failed with mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985 --scope -- mount -t xfs -o dir_mode=0777,file_mode=0777,uid=1000,gid=1000,defaults /dev/disk/azure/scsi1/lun2 /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985
Output: Running scope as unit run-rb21966413ab449b3a242ae9b0fbc9398.scope.
mount: wrong fs type, bad option, bad superblock on /dev/sde,
missing codepage or helper program, or other error
Cause
Azure disk uses the ext4/xfs filesystem by default, and mounting options such as uid=x,gid=x
can't be set at mount time.
Workaround 1: Use a pod security context to specify the user and group
Configure the security context for a pod. In the pod configuration file (YAML format), within the spec
/securityContext
field, set the runAsUser
field to the previously specified uid
value, and set the fsGroup
field to the previously specified gid
value. For example, the beginning of the configuration file might resemble the following code:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 0
fsGroup: 0
Note
By default, the gid
and uid
options are mounted as root or 0. If those options are set as non-root (such as 1000), Kubernetes will use the change owner command (chown
) to change all directories and files within that disk. This operation can be time-consuming, and it might make the disk-mounting operation very slow.
Workaround 2: Use an init container and the change owner command to specify the user and group
Set up an init container, and then run a chown command that specifies the user and group values in the container. The following code shows how to set up an init container to set the user and group:
initContainers:
- name: volume-mount
image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
command: ["sh", "-c", "chown -R 100:100 /data"]
volumeMounts:
- name: <your-data-volume>
mountPath: /data
Third-party information disclaimer
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
Contact us for help
If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure feedback community.