• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue plesk repair fs fails with custom DKIM selector: expected file but found symlink

brother4

Basic Pleskian
Server operating system version
Ubuntu 24.04.4 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.79
Hello,

I am using Plesk Obsidian 18.0.79 Web Host Edition.

For one domain, I have enabled DKIM signing via the Plesk UI and created/activated a custom DKIM selector named hosting.

In the Plesk UI, the domain mail settings show:

Use DKIM spam protection system to sign outgoing email messages: enabled
Active DKIM selector: hosting (Active)

After running: plesk repair all -y
or specifically the filesystem repair, Plesk reports an error for the DomainKeys directory:

The permissions on the /etc/domainkeys directory are incorrect .... [ERROR]

fsmng failed: ERROR: Expected and actual types of file
'/etc/domainkeys/example.com/default' do not match: file != symlink.
The current file structure looks like this:

ls -la /etc/domainkeys/example.com/

default -> /etc/domainkeys/example.com/hosting
hosting
So default is a symbolic link pointing to the active custom DKIM selector key file hosting.

My assumption is that this symlink was created by Plesk itself when the custom DKIM selector was created or activated via the UI. DKIM signing appears to be configured through Plesk, not manually.

Questions:

  1. Is this symlink structure expected when using a custom DKIM selector?
  2. If yes, is it a bug that plesk repair fs expects /etc/domainkeys/example.com/default to be a regular file instead of accepting the symlink?
  3. What is the recommended way to fix this without manually replacing the symlink and potentially breaking Plesk-managed DKIM selector handling?
I would prefer not to manually modify /etc/domainkeys/... if this layout is managed by Plesk itself.

Thank you.
 
Hi, @brother4 . Do I correctly understand that you haven't manually created the symlink in question? According to my tests no such symlink is being created when a custom DKIM selector is configured and set for a domain.
 
Would it be possible to try creating another custom DKIM selector and then attempt to remove the symlink associated with "hosting"? Also, can you double-check if a symlink is being created for the new custom selector?
 
Back
Top