2023-10-11, 12:32 AM
Okay, before I start down this path, how about doing the maintenance that I like to do with every single time I stop/upgrade a container? First, make sure you have your persistent data saved. I see you have config and cache in there, so you should be good.
Stop the container, remove it (the force flag just skips "Do you really want to do that?!") and bring it back up. You have your config and cache saved, you'll be fine. Start here, it's the beauty of containers. You can also -- between docker compose rm -f jellyfin and bringing it back up -- prune your volumes, which will remove any docker volumes that might be holding on to data that you don't need. Note that if you don't have things configured properly, you will lose data, period. You're removing volumes that docker uses to dynamically store data with pruning, but it is essentially deleting the docker cache.
Again, --force just skips "OMG SERIOUSLY?!" and --all removes unused volumes, not just restricting the command to anonymous volumes that are not attached to a particular container. Jellyfin doesn't create volumes by default unless you don't specify where to store data, but this is a good step in clearing out the clutter and can make a difference. After the docker maintenance (whatever parts you choose to follow), proceed to what I actually typed up before I went down this rabbit hole...
What does ls -l look like for /Volumes/hdX/jellyfin-hdX? I'm only interested in permissions and whether any ACLs have been set, so just that line for each.
You could run (requires super user, but type that on your own):
And not bother with the ls command, which would just recursively set ownership of the files to your 1000 user and group, but I don't know what else you have poking around in those files so I hesitate to even recommend it. Way safer than chmod 777, though. The ls command would help you check for the next part -->
You should absolutely double check that Jellyfin has execute perms on the parent directories, which could present issues. At minimum the top-level directories, but you could incorporate a troubleshooting step of running chmod +x on UID 1000.
Code:
docker compose stop jellyfin && docker compose rm -f jellyfin && docker compose up -d jellyfin
Stop the container, remove it (the force flag just skips "Do you really want to do that?!") and bring it back up. You have your config and cache saved, you'll be fine. Start here, it's the beauty of containers. You can also -- between docker compose rm -f jellyfin and bringing it back up -- prune your volumes, which will remove any docker volumes that might be holding on to data that you don't need. Note that if you don't have things configured properly, you will lose data, period. You're removing volumes that docker uses to dynamically store data with pruning, but it is essentially deleting the docker cache.
Code:
docker volume prune --force --all
Again, --force just skips "OMG SERIOUSLY?!" and --all removes unused volumes, not just restricting the command to anonymous volumes that are not attached to a particular container. Jellyfin doesn't create volumes by default unless you don't specify where to store data, but this is a good step in clearing out the clutter and can make a difference. After the docker maintenance (whatever parts you choose to follow), proceed to what I actually typed up before I went down this rabbit hole...
What does ls -l look like for /Volumes/hdX/jellyfin-hdX? I'm only interested in permissions and whether any ACLs have been set, so just that line for each.
You could run (requires super user, but type that on your own):
Code:
chown -R 1000:1000 /Volumes/hd1/jellyfin-hd1
And not bother with the ls command, which would just recursively set ownership of the files to your 1000 user and group, but I don't know what else you have poking around in those files so I hesitate to even recommend it. Way safer than chmod 777, though. The ls command would help you check for the next part -->
You should absolutely double check that Jellyfin has execute perms on the parent directories, which could present issues. At minimum the top-level directories, but you could incorporate a troubleshooting step of running chmod +x on UID 1000.
Jellyfin 10.10.0 LSIO Docker | Ubuntu 24.04 LTS | i7-13700K | Arc A380 6 GB | 64 GB RAM | 79 TB Storage