<p>On macos the <code>:z</code> doesn't seems to do the trick :</p>
<pre class="lang-none prettyprint-override"><code>$ podman run -it --rm -v .:/data:z alpine
Error: preparing container 976...1f8 for attach: SELinux relabeling of /var/home/core is not allowed
</code></pre>
<p>But for some reason, using an absolute source path does:</p>
<pre class="lang-none prettyprint-override"><code>$ podman run -it --rm -v `pwd`:/data alpine 
/ # ls /data
&lt;... the files I expect ...&gt;
</code></pre>

CC BY-SA 4.0
2024-10-14T13:10:51.373Z
2024-10-14T13:17:57.707Z
2024-10-14T13:17:57.707Z
Zoyolin
<p>Thanks to the people <a href="https://old.reddit.com/r/podman/comments/fww87v/permission_denied_within_mounted_volume_inside/" rel="noreferrer">here</a>, the solution is quite simple (but not obvious):</p>

<p>My GNU/Linux container host has SELinux activated, and that's why I was having permissions problems. The solution is to simply append a <code>:z</code> to the <code>podman run</code> volume argument so that this:</p>

<p><code>podman run -it -v /host/foobar:/src_dir /bin/bash</code></p>

<p>becomes this:</p>

<p><code>podman run -it -v /host/foobar:/src_dir:z /bin/bash</code></p>

<p>That's it.</p>

CC BY-SA 4.0
2021-01-11T21:53:55.793Z
I 've spent so many hours trying to understand the cause of a similar error on my rpi4 running fedora iot, experimenting with linuxserver.io containers. Finally I understood the problem well enough that I was able to find this answer! Thank you! The following red hat post appears to have some more information
https://www.redhat.com/sysadmin/user-namespaces-selinux-rootless-containers
Karsus
CC BY-SA 4.0
2023-12-08T19:27:25.640Z
The `:z` flag is not supported in Mac OS. Any suggestions on a fix for that host env?
Jeremy
CC BY-SA 4.0
2024-03-20T09:40:37.090Z
@Jeremy but MacOS also doesn't run SELinux, does it? `:z` helps when the error is SELinux related, you likely have a different problem.
cafce25
CC BY-SA 4.0
2020-04-08T18:54:10.707Z
2020-04-08T18:54:10.707Z
hpy
<p>I am starting to learn about containers using <code>podman</code> that came with RHEL8.1 (which AFAIK can be used in place of <code>docker</code>), and have the following baby <code>Dockerfile</code> as a learning exercise:</p>
<pre><code># Use Alpine Linux base image
FROM alpine:latest

# Install pacakges
RUN apk --no-cache add bash gcc make

# Make a directory for source code
RUN mkdir /src_dir

# Set working directory to the same directory
WORKDIR /src_dir

# Set this directory as a volume
VOLUME [ &quot;/src_dir&quot; ]
</code></pre>
<p>As you can see, I've installed the most basic <code>gcc</code> and <code>make</code> into this container with the goal of mounting a set of source files on my container host into the <code>/src_dir</code> directory within the container.</p>
<p>I next build the container image in the host directory containing the <code>Dockerfile</code>:</p>
<pre><code>podman build -t my_image .
</code></pre>
<p>I then start the container with this command</p>
<pre><code>podman run -it -v /host/foobar:/src_dir /bin/bash
</code></pre>
<p>Where <code>/host/foobar/</code> on my host is an arbitrary directory containing some arbitrary source code, all of which my local user on the host has full read/write access to. For example, there is one file <code>/host/foobar/test.c</code>. This then brings me to a <code>bash</code> prompt inside the container. I can see that I'm at the correct place because:</p>
<pre><code>bash-5.0# pwd
/src_dir
</code></pre>
<p>However, I have absolutely no read/write access to <code>/src_dir</code>. Both <code>ls -lh</code> and <code>cat test.c</code> gave me permission denied errors. If I change to the root directory (or any other directory) of the container, I can see and access other things. Strangely, if I run <code>ls -lh /</code> I can see <code>/src_dir</code> as being owned by <code>root:root</code>, so I don't understand why as the container's root user I can't access anything in it.</p>
<p>I also tried <code>podman inspect [container ID]</code>, and in the output I can see:</p>
<pre><code>...
&quot;Mounts&quot;: [
            {
                &quot;Type&quot;: &quot;bind&quot;,
                &quot;Name&quot;: &quot;&quot;,
                &quot;Source&quot;: &quot;/host/foobar&quot;,
                &quot;Destination&quot;: &quot;/src_dir&quot;,
                &quot;Driver&quot;: &quot;&quot;,
                &quot;Mode&quot;: &quot;&quot;,
                &quot;Options&quot;: [
                    &quot;rbind&quot;
                ],
                &quot;RW&quot;: true,
                &quot;Propagation&quot;: &quot;rprivate&quot;
            }
        ]
...
</code></pre>
<p>Which suggests that there <em>is</em> read/write permission?</p>
<p>Perhaps I'm missing something obvious as a beginner, but what do I have to do so that I can run the <code>gcc</code> and <code>make</code> inside this container on the source files mounted in <code>/src_dir</code> <em>so that the container essentially acts as a complete development environment</em>?</p>

<permissions><volume><persistent-volumes><podman>
Permission denied within mounted volume inside Podman container
hpy
# Permission denied within mounted volume inside Podman container

(Asked by: username_0 on 2020-04-07)

I am starting to learn about containers using podman that came with RHEL8.1 (which AFAIK can be used in place of docker), and have the following baby Dockerfile as a learning exercise:
# Use Alpine Linux base image
FROM alpine:latest

# Install pacakges
RUN apk --no-cache add bash gcc make

# Make a directory for source code
RUN mkdir /src_dir

# Set working directory to the same directory
WORKDIR /src_dir

# Set this directory as a volume
VOLUME [ "/src_dir" ]

As you can see, I've installed the most basic gcc and make into this container with the goal of mounting a set of source files on my container host into the /src_dir directory within the container.
I next build the container image in the host directory containing the Dockerfile:
podman build -t my_image .

I then start the container with this command
podman run -it -v /host/foobar:/src_dir /bin/bash

Where /host/foobar/ on my host is an arbitrary directory containing some arbitrary source code, all of which my local user on the host has full read/write access to. For example, there is one file /host/foobar/test.c. This then brings me to a bash prompt inside the container. I can see that I'm at the correct place because:
bash-5.0# pwd
/src_dir

However, I have absolutely no read/write access to /src_dir. Both ls -lh and cat test.c gave me permission denied errors. If I change to the root directory (or any other directory) of the container, I can see and access other things. Strangely, if I run ls -lh / I can see /src_dir as being owned by root:root, so I don't understand why as the container's root user I can't access anything in it.
I also tried podman inspect [container ID], and in the output I can see:
...
"Mounts": [
            {
                "Type": "bind",
                "Name": "",
                "Source": "/host/foobar",
                "Destination": "/src_dir",
                "Driver": "",
                "Mode": "",
                "Options": [
                    "rbind"
                ],
                "RW": true,
                "Propagation": "rprivate"
            }
        ]
...

Which suggests that there is read/write permission?
Perhaps I'm missing something obvious as a beginner, but what do I have to do so that I can run the gcc and make inside this container on the source files mounted in /src_dir so that the container essentially acts as a complete development environment?

**Tags:** permissions, volume, persistent-volumes, podman


---

## 2 answers

### Answer by username_0 on 2020-04-08. Score: 22 | Accepted answer

Thanks to the people [here](https://old.reddit.com/r/podman/comments/fww87v/permission_denied_within_mounted_volume_inside/), the solution is quite simple (but not obvious):

My GNU/Linux container host has SELinux activated, and that's why I was having permissions problems. The solution is to simply append a `:z` to the `podman run` volume argument so that this:

`podman run -it -v /host/foobar:/src_dir /bin/bash`

becomes this:

`podman run -it -v /host/foobar:/src_dir:z /bin/bash`

That's it.

> **Comments:**
> **username_2**: I 've spent so many hours trying to understand the cause of a similar error on my rpi4 running fedora iot, experimenting with linuxserver.io containers. Finally I understood the problem well enough that I was able to find this answer! Thank you! The following red hat post appears to have some more information https://www.redhat.com/sysadmin/user-namespaces-selinux-rootless-containers  
> **username_3**: The `:z` flag is not supported in Mac OS. Any suggestions on a fix for that host env?  
> **username_4**: @username_3 but MacOS also doesn't run SELinux, does it? `:z` helps when the error is SELinux related, you likely have a different problem.  

---

### Answer by username_1 on 2024-10-14. Score: 0

On macos the :z doesn't seems to do the trick :
$ podman run -it --rm -v .:/data:z alpine
Error: preparing container 976...1f8 for attach: SELinux relabeling of /var/home/core is not allowed

But for some reason, using an absolute source path does:
$ podman run -it --rm -v `pwd`:/data alpine 
/ # ls /data
<... the files I expect ...>


---

