plesk repair is the CLI that rebuilds Plesk-managed configuration from the panel
database. It is not a generic "fix everything" button — each subcommand has a defined
scope, and running the wrong one wastes 20 minutes or worse, restarts a service in the
middle of a customer's mail check.
This is what each subcommand actually touches, when to reach for it, and the flags that keep production safe.
What plesk repair actually does
The utility reads the authoritative state of objects (domains, mailboxes, databases,
subscriptions) from the psa database, compares it against on-disk configuration, and
rewrites the on-disk configuration to match. It does not repair the psa database
itself — for that you need plesk db check and plesk db repair, which are separate.
In practice that means plesk repair is the right tool when:
- The panel believes a domain exists but Apache, Nginx, Dovecot, or Postfix cannot find its config.
- File ownership drifted (a backup restore put files back as
root:root). - A package update reset a vhost template and you need to regenerate every vhost from it.
It is the wrong tool when:
- The
psadatabase is itself corrupted (mailboxes missing from the panel, subscriptions not listed). Repair will faithfully recreate the broken state. - A Plesk autoinstaller fetch is failing. That is a network or catalogue problem; rewriting vhosts will not help.
- Components show as "not configured" after
an upgrade. Run
plesk installerfirst; repair is step three, not step one.
Choose the right scope
There are five top-level scopes. Always prefer the narrowest one that covers the symptom.
plesk repair web
Rewrites Apache (/etc/httpd/conf/plesk.conf.d/) and Nginx (/etc/nginx/plesk.conf.d/)
vhost configurations from the panel database, regenerates .htaccess where Plesk
manages it, and reapplies hosting settings (PHP handler, CGI, SSI) per subscription.
Reach for it when:
- Apache or Nginx fails to start after a Plesk update reset the vhost template.
- A site returns the Plesk default page instead of customer content (the vhost did not rebuild after a domain was added).
- SSL certificates are installed in the panel but Nginx isn't presenting them.
plesk repair web -y
The -y flag skips the per-domain confirmation prompt. On a server with 300 subscriptions
the prompts will run you out of patience inside the first 30 seconds.
To repair a single domain:
plesk repair web example.com -y
Single-domain repair is fast (under 5 seconds) and safe to run during business hours.
Fleet-wide plesk repair web -y triggers an Apache and Nginx reload at the end — schedule
it during a low-traffic window.
plesk repair mail
Rebuilds Postfix maps (/var/spool/postfix/plesk/), Dovecot mailbox locations
(/etc/dovecot/conf.d/), and per-mailbox passwords from the psa database. Also fixes
maildir ownership inside /var/qmail/mailnames/ (Qmail) or /var/vmail/ (Postfix).
Reach for it when:
- Mailboxes accept a password in webmail but reject the same password over IMAP.
- New mailboxes don't appear in the Dovecot user database until you restart
dovecot. - After a host migration, mail moves into
/var/vmail/domain.tld/but users can't read it (ownership drift).
plesk repair mail -y
If only one domain's mail is broken, scope it:
plesk repair mail example.com -y
This restarts Postfix and Dovecot at the end. Active IMAP IDLE connections will reconnect within seconds; SMTP submissions in flight may bounce. Run during a quiet window or wrap it with outbound throttling to control the retry storm.
plesk repair db
Rebuilds the contents of /etc/psa/private/secret_key-derived MySQL grants for
Plesk-managed databases. It does not repair MySQL itself — broken InnoDB tables or
corrupt ibdata still need mysqlcheck.
Reach for it when:
- A customer can log into the panel but
wp-config.phpcredentials no longer authenticate. - The panel shows a database but
mysql -u admin -p$(plesk db get-admin-password) <name>fails with access denied. - A WordPress site logs
Error establishing database connectionimmediately after a host rename or IP change.
plesk repair db -y
This is one of the safer subcommands: it only rewrites grant tables, with no service restart. Run it any time.
plesk repair fs
Walks the filesystem and resets ownership, group, and (selectively) mode bits on
/var/www/vhosts/<domain>/, mail directories, and Plesk's own state directories. This is
the scope that genuinely fixes "I ran chown -R root:root by accident on someone's
docroot".
plesk repair fs -y
It is slow — expect 1–2 minutes per 10 GB of vhost data, and significantly more if you
have many small files (typical for a busy WordPress fleet). Do not run it under load: the
walk traverses every file the user accounts own, and stat() storms on a packed SSD can
push iowait above 50%.
To scope to one subscription:
plesk repair fs example.com -y
plesk repair all
Runs web, mail, db, and fs in sequence. This is the answer when every layer is
broken at once — typically after restoring a full Plesk backup to a fresh server, or
recovering from a botched dist-upgrade.
plesk repair all -y
On a server with 200 subscriptions and 500 GB of vhost data, expect 30–90 minutes. The operation is interruptible (Ctrl-C is safe) but resuming starts the current scope from the beginning.
Useful flags
-y— skip interactive prompts. Required for any non-interactive script.--no-restart— apply changes but do not restart Apache, Nginx, Postfix, or Dovecot. Use this when you are running repair as part of a larger maintenance window and will restart services in a controlled batch.--report-only— produce the report without writing changes. Always run this first if you are repairing a customer-facing server and have not run repair in months. The output goes to stdout and a JSON report under/var/log/plesk/repair-<scope>-<ts>.log.--debug— verbose tracing. Only useful when filing a Plesk support ticket; the volume is not human-readable.
A safe production sequence:
plesk repair web --report-only -y > /tmp/repair-web-preview.log
less /tmp/repair-web-preview.log # review the planned changes
plesk repair web --no-restart -y # apply without service restart
plesk sbin httpdmng --reconfigure-all
systemctl reload nginx httpd # batch the restarts yourself
When repair makes things worse
Three cases where running repair will damage a working server.
A customer added custom Apache/Nginx directives via vhost.conf and you haven't
included them in vhost_nginx.conf. plesk repair web rewrites from the panel-managed
template; the vhost.conf and vhost_nginx.conf includes survive only if they
existed before the run. If you let Plesk regenerate during a transition where one of the
include files is missing, the customisation is dropped. Run
plesk bin server_pref --update -reload-conf true afterwards if you've staged includes
into place.
A migration is mid-flight. If you are using
Plesk Migrator and a subscription is partially imported,
plesk repair will treat the half-imported state as authoritative and rewrite mail and
web configs around it. Wait until the migration tool reports success.
Custom MySQL grants for application users. plesk repair db rewrites grants for
panel-managed users only — but if you have manually granted access to a
plesk_admin_application user that the panel does not know about, the repair will leave
it alone but a subsequent plesk repair all may reset the wider grant state in ways that
take effect on the next FLUSH PRIVILEGES. Document custom grants outside the panel and
re-apply them after repair runs.
Reading the report
The report's format is consistent across scopes:
example.com:
[+] Configuration of web server: OK
[!] Configuration of mail server: REGENERATED
[-] DNS zone: SKIPPED (no DNS service on this server)
[+]— checked, no change needed.[!]— rewritten or restarted.[-]— skipped, with the reason.[E]— error. Look in/var/log/plesk/panel.logfor the timestamp; the error block there has the underlying exception.
A clean run with zero [!] lines after a quiet period is the baseline. If every weekly
run produces hundreds of [!] entries, something else on the server is mutating
configuration between runs — frequently a misconfigured backup restore, or an automation
tool writing to /etc/httpd/conf/plesk.conf.d/ directly.
Next steps
- For the upstream symptom of broken components after a patch, see Plesk "server components not configured".
- If repair is needed because an update never finished, start at Fix Plesk update failures.
- Licensing tier affects which components Plesk will rebuild — check the Plesk license tier breakdown if a repair leaves a component permanently disabled.