I started using Yarrlist and ran into a problem I can’t figure out on my own. Something changed while I was setting it up, and now it isn’t working the way I expected. I need help troubleshooting Yarrlist so I can get it running correctly again.
Start with the boring checks first. Yarrlist usually breaks for one of 5 reasons.
-
URL or base path changed.
If you moved it behind a reverse proxy, check the app URL, port, and subpath. Example, /yarrlist vs /. A bad base URL causes broken login, blank pages, and redirects. -
Config got overwritten.
Look at your config file or env vars. Compare old and new values. Focus on database path, API keys, auth settings, and bind address. One wrong value is enough. -
Permissions issue.
If Yarrlist writes to a DB, cache, or media folder, make sure your user has read and write access. This hits a lot after Docker changes. Run a quick test by creating a file in the mounted folder. -
Database mismatch.
If you updated versions, the schema might be out of date. Check logs for migration errors, sqlite lock errors, or missing table messages. Logs usually tell the story fast. -
Browser cache or stale session.
Log out. Clear site data. Try another browser. Sounds dumb, fixes stuff more often than ppl admit.
What to post next if you want real help:
Yarrlist version.
How you installed it, Docker, bare metal, etc.
What changed.
Exact error text.
Relevant logs.
A screenshot if the UI is busted.
If you use Docker, also post your compose file with secrets removed. That saves a lot of back and forth.
I’d check one thing before going too deep into config hunting: whether Yarrlist is actually failing, or if a dependency around it is. People blame the app first, but half the time it’s DNS, the proxy container, or the volume mount silently not loading.
A few diff checks that complement what @nachtdromer said:
- Open browser dev tools, Network tab, reload the page, and see what request is failing. 401, 403, 404, 500 tells you a lot fast.
- Check container restarts. If it keeps restarting every few seconds, the app itself may never be fully up.
- Verify your mounted paths are the same inside the container as what Yarrlist expects. I kinda disagree that permissions are always the first suspect. Wrong mount target bites ppl just as often.
- If this started right after an update, try rolling back one version just to confirm whether it’s a regression.
- Inspect timestamps on config/db files. Sometimes the “changed while setting it up” part is just Docker recreating stuff and loading a blank file.
If you want sharper help, post:
- what “isn’t working” means exactly
- logs from startup
- compose yaml
- whether the issue is UI, login, importing, or saving
Without that, everyone is just guessing tbh.
What changed matters more than the symptom sometimes. I’d make a quick timeline first for Yarrlist:
- Last thing edited before it broke: env vars, reverse proxy, image tag, storage path, auth?
- Test Yarrlist directly on its mapped port, bypassing proxy/CDN/auth middleware.
- Open the app in a private window. Cached JS and stale cookies can make a healthy app look broken.
- Compare current env/config against a known-good backup or the compose you originally intended. A single renamed variable can brick startup behavior without obvious logs.
- Check system time inside the container and host. I disagree a bit with chasing only network errors first. If sessions, tokens, or API validation depend on time, clock drift causes weird login/save failures.
@nachtdromer is right to separate app failure from surrounding stack issues, but I’d also verify browser console errors, not just network responses.
Pros of Yarrlist: lightweight, flexible, easy to self-host.
Cons of Yarrlist: setup can be brittle, updates can expose config mistakes, troubleshooting usually needs logs plus compose.
If you post the exact failure text and redacted config, people can narrow it down fast.