Podman container doesn't start after system update
Podman container doesn't start after system update
After an automatic update+reboot of my Debian server my Jellyfin container doesn't work anymore. When I try to run it from the command line I get:
Error: crun: make '/home/serve/.local/share/containers/storage/vfs/dir/[string]' private: Permission denied: OCI permission denied
Here's the list of updated packages, in case it's useful:
base-files buildah curl dns-root-data intel-microcode libc-bin libc-l10n libc6 libcurl3-gnutls libcurl4 libmariadb3 libpam-systemd libpq5 librabbitmq4 libsystemd-shared libsystemd0 libudev1 linux-image-amd64 locales mariadb-common systemd systemd-sysv tzdata udev vim vim-common vim-runtime vim-tiny wget
I tried doing some searching and it looks like a podman issue, but with no real fix for it? Not sure tbh. Do I need to nuke my container and start again? Or is there a way to fix this while keeping my config?
Small update: I did some digging around in the directories that error out and found that in ~/.local/share/containers/storage/volumes both the jellyfin-cache and jellyfin-config folders are owned by 100000, but they were the only ones. I tried changing ownership to my user but the error persists.
Looks like a permissions issue on the storage volume to me. Check the file mentioned and compare with the others.
Seems like that may have gotten altered sometime before the update and restarting triggered the failure (the update likely being incidental).
I already tried that, but I couldn't access it without becoming root. The
dirfolder is owned by100000which I assumed is by design and I didn't want to mess up any of my other containers and left it be. But I just noticed that the folder that gives the error doesn't exist at all, don't know if that has anything to do with it. I also tried removing Jellyfins images and redownloading them but nothing changes.Are you logged in as the owner of this home directory (presumably "serve")? If not, you should attempt to or assume it (
su). If you are, then you seem to have located a likely culprit.I really don't think this has anything to do with the upstream images, but something that has happened to the container's storage volume.