Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-10-14T13:10:51.373Z
Answers: 2024-10-14T13:17:57.707Z
Answers: 2024-10-14T13:17:57.707Z
Answers: Zoyolin
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-11T21:53:55.793Z
Answers: 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
Answers: Karsus
Answers: CC BY-SA 4.0
Answers: 2023-12-08T19:27:25.640Z
Answers: The `:z` flag is not supported in Mac OS. Any suggestions on a fix for that host env?
Answers: Jeremy
Answers: CC BY-SA 4.0
Answers: 2024-03-20T09:40:37.090Z
Answers: @Jeremy but MacOS also doesn't run SELinux, does it? `:z` helps when the error is SELinux related, you likely have a different problem.
Answers: cafce25
Answers: CC BY-SA 4.0
Answers: 2020-04-08T18:54:10.707Z
Answers: 2020-04-08T18:54:10.707Z
Answers: hpy
Body: <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>
  
Tags: <permissions><volume><persistent-volumes><podman>
Title: Permission denied within mounted volume inside Podman container
UserDisplayName: hpy
ThreadText: # 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 :
  
  ```none
  $ 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:
  
  ```none
  $ podman run -it --rm -v `pwd`:/data alpine 
  / # ls /data
  <... the files I expect ...>
  
  ```
  
  
  ---
  
  