---
name: openshift-ts-app-05-scc
title: Why does my pod not build with a permission denied error because of security context constraint (SCC)?
description: Learn how to resolve permission denied errors related to security context constraints (SCC) when building or running pods.
last-updated: 2026-04-09
---

> ## 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.

# Why does my pod not build with a permission denied error because of security context constraint (SCC)?
{: #ts-app-scc}
{: troubleshoot}
{: support}

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

Learn how to resolve permission denied errors related to security context constraints (SCC) when building or running pods.
{: shortdesc}

A system pod or other pod that uses a security context constraint (SCC) has an operation that keeps retrying but fails with a `permission denied` error. For example, you might log in to the internal `image-registry` pod and try to run a `docker push` command.
{: tsSymptoms}

Example error message when pushing an image to the internal registry.
```sh
error: build error: Failed to push image: error copying layers and metadata
```
{: screen}


The pod might use an SCC or belong to a system group that uses an SCC without the correct permissions. You might have added a system group to an SCC by running the `oc adm policy add-scc-to-group <scc> system:<group>` command.
{: tsCauses}

If the pod mounts a volume, the pod's permissions that are authorized by the SCC might no longer allow the pod to read or write data to the volume.

For example, the internal registry mounts a volume to read and write image data to a file storage instance. If the `system:authenticated` group that the internal registry belongs to changes the SCC from `restricted` to `anyuid`, then the pod runs with a different UID. The different UID prevents the internal registry pod from pushing or pulling images from the storage device.


Change the pod's SCC permissions.
{: tsResolve}

1. Describe the pod and check the `openshift.io/scc: <scc>` security context constraint in the **Annotations** section.
    ```sh
    oc describe pod -n <project> <pod>
    ```
    {: pre}

    Example output

    ```sh
    NAME:               image-registry-1234567
    Namespace:          openshift-image-registry
    Priority:           2000000000
    PriorityClassName:  system-cluster-critical
    Node:               10.xxx.xx.xxx/10.xxx.xx.xxx
    Start Time:         Wed, 19 Feb 2020 15:38:53 -0500
    Labels:             docker-registry=default
    Annotations:        openshift.io/scc: anyuid
    ```
    {: screen}

2. Describe the security context constraint and check the user and groups in the **Access** section.
    ```sh
    oc describe scc <scc>
    ```
    {: pre}

    Example output

    ```sh
    NAME:                        anyuid
    Priority:                    <none>
    Access:                        
        Users:                    <none>
        Groups:                    system:authenticated
    ```
    {: screen}

3. If you don't want the user or group to have the permissions of the SCC, remove the user or group from the SCC. For more information, review the default [Red Hat OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc&format=markdown#oc_sccs) and [IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc&format=markdown#ibm_sccs) SCCs that are set in the cluster.
    ```sh
    oc adm policy remove-scc-from-group <scc> <(user|group)>
    ```
    {: pre}

4. Add the user or group to the SCC with the appropriate permissions.
    ```sh
    oc adm policy add-scc-to-group <scc> <(user|group)>
    ```
    {: pre}

5. Delete the pod so that the pod is rescheduled with the new SCC permissions.
    ```sh
    oc delete pod -n <project> <pod>
    ```
    {: pre}