Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
What do the logs say?
Can't see pictrs log because it never full starts.
If the pictrs container doesn't start check the docker logs.
journalctl -fexu docker
It'll typically tell you why a container isn't starting, usually a broken bind mount.
To prevent this from happening again, try migrating to an S3 backend; DigitalOcean have one that's fixed-price and includes egress, so you can't accidentally end up with a ridiculous bill one month!
You can still see the logs using
docker logs container_name>
. To get the container name you can usedocker ps -a
. It should list the pictrs container there. The container name is usually the last column of the output.` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering. 2023-08-26T20:46:43.679371Z WARN sled::pagecache::snapshot: corrupt snapshot file found, crc does not match expected Error: 0: Error in database 1: Read corrupted data at file offset None backtrace ()
Location: src/repo/sled.rs:84
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
0: pict_rs::repo::sled::build with path="/mnt/sled-repo" cache_capacity=67108864 export_path="/mnt/exports" at src/repo/sled.rs:78 1: pict_rs::repo::open with config=Sled(Sled { path: "/mnt/sled-repo", cache_capacity: 67108864, export_path: "/mnt/exports" }) at src/repo.rs:464
root@Lemmy:~#`
Seems like your pictrs database is corrupted.
Is there a way to reset the pictrs DB without affecting the posts, commenst and users DB?
You can try mounting a new folder as pictrs volume. I assume your other data will be safe since it is in the database.
pictrs database is completely separate from lemmy database. If you want you just delete everything in the pictrs volume and start afresh. You will lose all images though.
There's only two local posts on my instance so i'm not worried about losing thoseabout.
Will the pictrs from subscribed communities in other instances be restored after a db reset?
Dont worry about those. Those images are not stored by your pictrs instance. They are directly fetched from the native instances.
OK. I just deleted the pictrs folder from srv/lemmy/leemyalone.org/volumes but I am still having the same issue.
You'll have to check again. My guess is though you should not have deleted the pictrs folders. Just its contents. You can recreate the folder again though:
But check the logs first.
In my previous comment I should have mentioned that I did recreate the pictrs folder. Your instruction to change set the ownership of the pictures folder to 991:991 did the trick.
Thank you so much for your help here. Much appreciated.