Panellicense

Plesk repair utility — fix web, mail, db, and filesystem from CLI

When to run plesk repair web, mail, db, fs, or all — the scope each subcommand actually covers, the flags that prevent downtime, and the cases where repair makes things worse.

9 min readUpdated 2026-05-17plesk · repair · cli · maintenance
schema: HowToschema: FAQPageschema: BreadcrumbList

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 psa database 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 installer first; 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.php credentials 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 connection immediately 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.log for 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

Does plesk repair fix MariaDB or MySQL corruption?+
No. It only rewrites grant tables for Plesk-managed users. For corrupted tables run mysqlcheck --auto-repair on the affected database, and for InnoDB issues consult the MySQL error log — Plesk repair cannot help.
Is it safe to run plesk repair all on a production server during business hours?+
Only with --no-restart. The default run reloads Apache, Nginx, Postfix, and Dovecot at the end of each scope, which causes brief disconnects on active SMTP and IMAP sessions. Use --report-only first, --no-restart to apply, then schedule the service restarts.
Why does plesk repair web change my customer's custom Nginx directives?+
It does not change directives that live in vhost_nginx.conf or vhost.conf — but if those files are missing at run time, the regenerated vhost will not include them. Make sure custom include files exist before running repair, and use plesk bin subscription --update -reload-conf true to re-include them if needed.
What is the difference between plesk repair and plesk reconfigure?+
plesk reconfigure is an alias for the older diagnose-repair tool and is preserved for backward compatibility. New installs should use plesk repair. The scoping (web, mail, db, fs, all) is identical.
How often should I run plesk repair as preventative maintenance?+
Don't. Repair is a diagnostic and recovery tool, not a cron job. Routine runs hide drift instead of surfacing the underlying cause — a backup tool resetting permissions, a stale vhost template, or an unmanaged package update. Investigate the cause; only run repair as needed.
Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.