Bug: Database fails to apply migrations when running rootless #577
Description
Describe the bug
I'm running the container rootless (user: x:x in the compose). When I upgraded to v0.57.0 I started getting 500 error when opening a wishlist. From the logs it looks like mostWanted column is missing, which suggests that the migrations weren't applied. In the logs, there were no messages about the migration, but some errors from prisma:
cmintey-wishlist | 2025-12-14T14:25:41.098320361Z warn The configuration property `package.json#prisma` is deprecated and will be removed in Prisma 7. Please migrate to a Prisma config file (e.g., `prisma.config.ts`).
cmintey-wishlist | 2025-12-14T14:25:41.098364911Z For more information, see: https://pris.ly/prisma-config
cmintey-wishlist | 2025-12-14T14:25:41.098392552Z
cmintey-wishlist | 2025-12-14T14:25:41.128321695Z Error: Can't write to /usr/src/app/node_modules/.pnpm/@prisma+engines@6.19.0/node_modules/@prisma/engines please make sure you install "prisma" with the right permissions.
cmintey-wishlist | 2025-12-14T14:25:42.160235399Z warn The configuration property `package.json#prisma` is deprecated and will be removed in Prisma 7. Please migrate to a Prisma config file (e.g., `prisma.config.ts`).
cmintey-wishlist | 2025-12-14T14:25:42.160299630Z For more information, see: https://pris.ly/prisma-config
cmintey-wishlist | 2025-12-14T14:25:42.160311120Z
cmintey-wishlist | 2025-12-14T14:25:42.188625031Z Error: Can't write to /usr/src/app/node_modules/.pnpm/@prisma+engines@6.19.0/node_modules/@prisma/engines please make sure you install "prisma" with the right permissions.
I restarted the container as root and the migrations ran successfully. Then I restarted it rootless again and everything seems to work fine again. However, I'm still getting the prisma errors from above.
Note: There are also these errors in the log, but they seem to be "harmless" (the app works fine):
cmintey-wishlist | 2025-12-14T14:25:40.022193081Z {"level":"error","ts":1765722340.022153,"msg":"unable to create folder for config autosave","dir":"/.config/caddy","error":"mkdir /.config: permission denied"}
cmintey-wishlist | 2025-12-14T14:25:40.022255292Z {"level":"warn","ts":1765722340.0222182,"logger":"tls","msg":"unable to get instance ID; storage clean stamps will be incomplete","error":"mkdir /.local: permission denied"}
cmintey-wishlist | 2025-12-14T14:25:40.022327653Z {"level":"error","ts":1765722340.0222964,"logger":"tls","msg":"could not clean default/global storage","error":"unable to acquire storage_clean lock: creating lock file: open /.local/share/caddy/locks/storage_clean.lock: no such file or directory"}
Also, they are easy to resolve by mounting the corresponding folders with proper permissions.
To Reproduce
Steps to reproduce the behavior:
- Use explicit version tags (i.e.,
ghcr.io/cmintey/wishlist:v0.56.0). - Run the container rootless (e.g.,
user: 1500:1500in thedocker-compose.yml). - Update the version tag to the new version (i.e.,
v0.57.0). - Deploy the updated container.
Expected behavior
The version migrations are applied successfully and the container runs without issues.
Logs
See the log in the description.
Screenshots
N/A