diff options
Diffstat (limited to 'troubleshooting.md')
| -rw-r--r-- | troubleshooting.md | 42 |
1 files changed, 30 insertions, 12 deletions
diff --git a/troubleshooting.md b/troubleshooting.md index 8bce8e50f..f59963271 100644 --- a/troubleshooting.md +++ b/troubleshooting.md @@ -42,7 +42,7 @@ $ podman run -v ~/mycontent:/content:Z fedora touch /content/file Make sure the content is private for the container. Do not relabel system directories and content. Relabeling system content might cause other confined services on your machine to fail. For these -types of containers we recommend that disable SELinux separation. The option `--security-opt label=disable` +types of containers we recommend having SELinux separation disabled. The option `--security-opt label=disable` will disable SELinux separation for the container. $ podman run --security-opt label=disable -v ~:/home/user fedora touch /home/user/file @@ -157,7 +157,7 @@ When rootless Podman attempts to execute a container on a non exec home director #### Symptom If you are running Podman or Buildah on a home directory that is mounted noexec, -then they will fail. With a message like: +then they will fail with a message like: ``` podman run centos:7 @@ -166,7 +166,7 @@ standard_init_linux.go:203: exec user process caused "permission denied" #### Solution -Since the administrator of the system setup your home directory to be noexec, you will not be allowed to execute containers from storage in your home directory. It is possible to work around this by manually specifying a container storage path that is not on a noexec mount. Simply copy the file /etc/containers/storage.conf to ~/.config/containers/ (creating the directory if necessary). Specify a graphroot directory which is not on a noexec mount point and to which you have read/write privileges. You will need to modify other fields to writable directories as well. +Since the administrator of the system set up your home directory to be noexec, you will not be allowed to execute containers from storage in your home directory. It is possible to work around this by manually specifying a container storage path that is not on a noexec mount. Simply copy the file /etc/containers/storage.conf to ~/.config/containers/ (creating the directory if necessary). Specify a graphroot directory which is not on a noexec mount point and to which you have read/write privileges. You will need to modify other fields to writable directories as well. For example @@ -229,7 +229,7 @@ Rootless Podman requires the user running it to have a range of UIDs listed in / #### Symptom -An user, either via --user or through the default configured for the image, is not mapped inside the namespace. +A user, either via --user or through the default configured for the image, is not mapped inside the namespace. ``` podman run --rm -ti --user 1000000 alpine echo hi @@ -279,7 +279,7 @@ grep johndoe /etc/subuid /etc/subgid ### 11) Changing the location of the Graphroot leads to permission denied When I change the graphroot storage location in storage.conf, the next time I -run Podman I get an error like: +run Podman, I get an error like: ``` # podman run -p 5000:5000 -it centos bash @@ -323,7 +323,7 @@ Pulling an anonymous image that doesn't require authentication can result in an #### Symptom If you pull an anonymous image, one that should not require credentials, you can receive -and `invalid username/password` error if you have credentials established in the +an `invalid username/password` error if you have credentials established in the authentication file for the target container registry that are no longer valid. ``` @@ -991,12 +991,15 @@ less: dir1/a: Permission denied #### Solution -If you want to read or remove such a file, you can do so by entering a user namespace. -Instead of running commands such as `less dir1/a` or `rm dir1/a`, you would need to -prepend the command-line with `podman unshare`, i.e., -`podman unshare less dir1/a` or `podman unshare rm dir1/a`. To be able to use Bash -features, such as variable expansion and globbing, you need to wrap the command with -`bash -c`, e.g. `podman unshare bash -c 'ls $HOME/dir1/a*'`. +If you want to read, chown, or remove such a file, enter a user +namespace. Instead of running commands such as `less dir1/a` or `rm dir1/a`, you +need to prepend the command-line with `podman unshare`, i.e., +`podman unshare less dir1/a` or `podman unshare rm dir1/a`. To change the ownership +of the file _dir1/a_ to your regular user's UID and GID, run `podman unshare chown 0:0 dir1/a`. +A file having the ownership _0:0_ in the user namespace is owned by the regular +user on the host. To use Bash features, such as variable expansion and +globbing, you need to wrap the command with `bash -c`, e.g. +`podman unshare bash -c 'ls $HOME/dir1/a*'`. Would it have been possible to run Podman in another way so that your regular user would have become the owner of the file? Yes, you can use the options @@ -1174,3 +1177,18 @@ A side-note: Using [__--userns=keep-id__](https://docs.podman.io/en/latest/markd can sometimes be an alternative solution, but it forces the regular user's host UID to be mapped to the same UID inside the container so it provides less flexibility than using __--uidmap__ and __--gidmap__. + +### 35) Images in the additional stores can be deleted even if there are containers using them + +When an image in an additional store is used, it is not locked thus it +can be deleted even if there are containers using it. + +#### Symptom + +WARN[0000] Can't stat lower layer "/var/lib/containers/storage/overlay/l/7HS76F2P5N73FDUKUQAOJA3WI5" because it does not exist. Going through storage to recreate the missing symlinks. + +#### Solution + +It is the user responsibility to make sure images in an additional +store are not deleted while being used by containers in another +store. |