Admin Tools

A few admin commands ship on PATH, alongside the systemd-managed services. All of them require running as root (or as the seafile system user directly) - they re-exec as seafile themselves if invoked as anyone else, so sudo is enough.

seahub-reset-admin

Creates or resets a Seahub superuser account. Needs seafile.service running (it talks to seaf-server over its RPC socket).

Interactively:

sudo seahub-reset-admin

Non-interactively (e.g. for provisioning scripts):

sudo seahub-reset-admin --noinput --username=admin --email=admin@example.com --password='choose-a-strong-password'

There's no automatic first-run admin account - run this once after the services are up, whether it's your very first admin or an additional one later.

seaf-gc

Garbage-collects orphaned blocks from the object store (deleted libraries, expired trash, etc.).

sudo systemctl stop seafile seafile-fileserver seahub
sudo seaf-gc
sudo systemctl start seafile seafile-fileserver seahub

seaf-gc refuses to run while seafile.service, seafile-fileserver.service, seahub.service or seafile-fuse.service are active - it needs exclusive access to the object store. This is a limitation of the community edition itself, not something this packaging can work around, and there's no automatic schedule - run it by hand or set up your own cron job, on whatever cadence suits your library sizes and churn.

Common options: --dry-run/-D (report without deleting), --rm-deleted/-r (also remove libraries deleted by users).

seaf-fsck

Checks (and optionally repairs) object store integrity, per-library. Same running-stack restriction as seaf-gc above.

sudo systemctl stop seafile seafile-fileserver seahub
sudo seaf-fsck              # check only
sudo seaf-fsck --repair     # check and repair
sudo systemctl start seafile seafile-fileserver seahub

seaf-dbctl

Manages the ccnet/seafile database schema - initial load, versioned upgrades, and the data's version stamp ($SEAFILE_DATA_DIR/current_version). Normally invoked automatically by seafile-migrate.service on every start; you shouldn't need to run it directly.

The one time you would: recovering from an interrupted upgrade (a crash or timeout mid-upgrade). The version stamp is updated after each individual schema step, not just once at the end, so simply running it again resumes from wherever it left off:

sudo seaf-dbctl upgrade

If your data directory has no version stamp at all but already contains data (e.g. a restored backup that predates this packaging), seaf-dbctl/seafile-migrate refuse to guess - see Upgrading for how to resolve that.