Can’t create PID file

Seafile Server
,
1

Hi folks,
I’m looking for a little assistance with my dockerised Seafile installation. I recently updated my NAS OS and for some reason Seafile’s database will no longer start up and throws an error. I’m presuming it’s a permissions issue but I’m being extra careful about fixing this as I’ve also realised my backup must have failed recently and there is content I really can’t afford to lose

The error the database throws is below. Any suggestions on how I can safely tackle this?

2025-01-03 14:39:14 0 [Note] Server socket created on IP: ‘0.0.0.0’.

2025-01-03 14:39:14 0 [Note] Server socket created on IP: ‘::’.

2025-01-03 14:39:14 0 [ERROR] mariadbd: Can’t create/write to file ‘/run/mysqld/mysqld.pid’ (Errcode: 13 “Permission denied”)

2025-01-03 14:39:14 0 [ERROR] Can’t start server: can’t create PID file: Permission denied

2

Hmmmm, ok I need someone to stop me before I break something! I tried giving all the directories 777 permissions (they were 770) to see if that helped, but nothing changed. I can’t really understand what has happened. Before the OS update everything was fine and all the other containers I’m running on this server and working fine

3

Is this seafile 11 or 12? And are you using the database container from seafile, or one of your own?

This is the kind of problem where docker significantly complicates troubleshooting. It looks to me like the mariadb program inside the container is complaining about not being able to write to /run/mysqld/mysqld.pid, but (assuming your are using the normal seafile docker configs) that is a path inside the container only, and isn’t related to any directory you can access from outside of the container. So it would be worth getting inside the container to see what’s going on.

docker exec -it seafile-mysql /bin/bash

Then try df -h and ls -lh /run /run/mysqld to see if maybe it’s run out of space, and what the permissions on that directory look like.

1 Like
4

Thanks for getting back to me! Fortunately I did manage to fix things in the end. You were spot on when you said docker confuses these kinds of issue and to be quite honest i’m still not entirely sure what caused the problem, but the fix for me was just updating all the containers which resulted in the database magically working again.
If nothing else it’s a reminder to stay on top of my backup processes which I’ve decided to spend some of my Saturday refining :slight_smile: