I managed to recreate the seafile database from scratch with only having access to seafile-data (your data basically). This work on the community edition, and you don’t have to export your library and re-upload it again. I guess you have already solved it by now but I post my solution for others to read if they manage to break their installation.
Note that only the data is restored. Everything about shared folders, libraries, groups etc are stored in the database, so that will be lost. What you will do is basically import your old libraries into a fresh seafile installation.
I did the following steps to get it working:
- Put
seafile-datain some secure location (backup). - Check the library
uuid's to restore inseafile-data/storage/blocks/. You basically have to guess which one is which. You can use/seaf-fsck --exportto get a better understanding what libraryuuid*s you want, but then you have to wait for your whole library to be exported. You can also just restore every library. - Setup
seafileserver from scratch in an empty folder. You can use the old one if you clean it out. Remember to moveseafile-datato someplace safe beforehand. - Start
seafileserver - Login as admin in web-ui and recreate user accounts.
- Stop seafile server (just in case).
- You need to replace the new “empty”
seafile-datadirectory with the old one from step 1. - Run
./seaf-fsck --repair <library-uuid-to-restore>. - Use a
mysqlclient to make seafile aware of the lost libraries (orsqlite3if you use that instead of mysql/mariadb). Do the following (replace values between <tags>):- use seafile_db;
- select * from Repo;
- insert into Repo (id, repo_id) values (<pick-unique-id>, “<library-uuid-to-restore>”);
- select * from RepoOwner;
- insert into RepoOwner (id, repo_id, owner_id) values (<pick-unique-id>,"<library-uuid-to-restore>", “<email-to-user-account-of-repo-owner-from-step-5>”);
- Now your seafile database should be fine. Start
seafileagain and if you have done it right, you should have access to your old files.