---
name: openshift-ts-storage-object-nonroot
title: Resolving non-root user access issues to files in IBM Cloud
description: Resolve non-root user access issues to files uploaded to IBM Cloud when using `runAsUser` in your app deployment, including permissions.
last-updated: 2026-08-12
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/openshift?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Resolving non-root user access issues to files in IBM Cloud
{: #cos_nonroot_access}
{: support}

Resolve non-root user access issues to files uploaded to IBM Cloud when using `runAsUser` in your app deployment, including permissions.
{: shortdesc}

[Virtual Private Cloud]{: tag-vpc} [Classic infrastructure]{: tag-classic-inf}


You uploaded files to your IBM Cloud Object Storage service instance by using the console or the REST API. When you try to access these files with a non-root user that you defined with `runAsUser` in your app deployment, access to the files is denied.
{: tsSymptoms}


In Linux, a file or a directory has three access groups: `Owner`, `Group`, and `Other`. When you upload a file to IBM Cloud Object Storage by using the console or the REST API, the permissions for the `Owner`, `Group`, and `Other` are removed. The permission of each file looks as follows:
{: tsCauses}

```sh
d--------- 1 root root 0 Jan 1 1970 <file_name>
```
{: screen}

When you upload a file by using the IBM Cloud Object Storage plug-in, the permissions for the file are preserved and not changed.


To access the file with a non-root user, the non-root user must have read and write permissions for the file. Changing the permission on a file as part of your pod deployment requires a write operation. IBM Cloud Object Storage is not designed for write workloads.
{: tsResolve}

Updating permissions during the pod deployment might prevent your pod from getting into a `Running` state.

To resolve this issue, before you mount the PVC to your app pod, create another pod to set the correct permission for the non-root user.

1. To check the permissions of your files in your bucket, create a configuration file for your `test-permission` pod and name the file `test-permission.yaml`.

    ```yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: test-permission
    spec:
      containers:
      - name: test-permission
         image: nginx
         volumeMounts:
         - name: cos-vol
         mountPath: /test
      volumes:
      - name: cos-vol
         persistentVolumeClaim:
         claimName: <pvc_name>
   ```
   {: codeblock}

1. Create the `test-permission` pod.

    ```sh
    oc apply -f test-permission.yaml
    ```
    {: pre}

1. Log in to your pod.

    ```sh
    oc exec test-permission -it bash
    ```
    {: pre}

1. Navigate to your mount path and list the permissions for your files.

    ```sh
    cd test && ls -al
    ```
    {: pre}

    Example output

    ```sh
    d--------- 1 root root 0 Jan 1 1970 <file_name>
    ```
    {: screen}

1. Delete the pod.

    ```sh
    oc delete pod test-permission
    ```
    {: pre}

1. Create a configuration file for the pod that you use to correct the permissions of your files and name it `fix-permission.yaml`.

    ```yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: fix-permission
      namespace: <namespace>
    spec:
      containers:
      - name: fix-permission
        image: busybox
        command: ['sh', '-c']
        args: ['chown -R <nonroot_userID> <mount_path>/*; find <mount_path>/ -type d -print -exec chmod u=+rwx,g=+rx {} \;']
        volumeMounts:
        - mountPath: "<mount_path>"
          name: cos-volume
      volumes:
      - name: cos-volume
        persistentVolumeClaim:
          claimName: <pvc_name>
    ```
    {: codeblock}

1. Create the `fix-permission` pod.

    ```sh
    oc apply -f fix-permission.yaml
    ```
    {: pre}

1. Wait for the pod to go into a `Completed` state.

    ```sh
    oc get pod fix-permission
    ```
    {: pre}

1. Delete the `fix-permission` pod.

    ```sh
    oc delete pod fix-permission
    ```
    {: pre}

1. Re-create the `test-permission` pod that you used earlier to check the permissions.

    ```sh
    oc apply -f test-permission.yaml
    ```
    {: pre}

## Verifying that the permissions for your files are updated
{: #verifying_file_permission_update}

1. Log in to your pod.

    ```sh
    oc exec test-permission -it bash
    ```
    {: pre}

1. Navigate to your mount path and list the permissions for your files.

    ```sh
    cd test && ls -al
    ```
    {: pre}

    Example output

    ```sh
    -rwxrwx--- 1 <nonroot_userID> root 6193 Aug 21 17:06 <file_name>
    ```
    {: screen}

1. Delete the `test-permission` pod.

    ```sh
    oc delete pod test-permission
    ```
    {: pre}

1. Mount the PVC to the app with the non-root user.

Set `runAsUser` and `fsGroup` to the same values in your deployment YAML.
{: important}

After you set the correct file permissions in your IBM Cloud Object Storage service instance, don't upload files by using the console or the REST API. Use the IBM Cloud Object Storage plug-in to add files to your service instance.
{: tip}