Resolved Permissions on some of the files packaged by Plesk are incorrect[ERROR] - Post 18.0.69 Upgrade

[learning_curve]

Server operating system version

Ubuntu 24.04.2 LTS

Plesk version and microupdate number

18.0.69

Previous to the 18.0.69 release of Plesk, we've not had an issue exactly the same as this.
In the 18.0.69 Change-log under "Linux" there is this entry:

The plesk repair fs command can now fix permissions and ownership of certain files related to the server’s mail system (for example, /var/lib/plesk/mail/handlers). (PPPM-14907)

The work carried out on this ^ may / may not be related. Hopefully, Plesk can advise:

Details:

a) Upgraded Plesk from 18.0.68 to 18.0.69 no immediate (noticeable) issues and some older, outstanding Plesk issues have been fixed, which is great.

b) Post upgrade and external checks, a quick GUI initial check via:

/modules/repair-kit/index.php/index

This detects errors which, once the repair option is utilized, doesn't actually solve the problem:

Repair Kit fixed all issues it could. If any issues were not fixed, please try fixing them manually or contact Plesk Support.

c) Switch to CLI and for completeness & run

plesk repair all -n

d) Everything is perfectly okay, apart from... (which is expected after the GUI results):

Checking Linux system files

The permissions on some of the files packaged by Plesk are incorrect[ERROR]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

e) Following those instructions, which is where the link to the Change-log may be a factor i.e. plesk repair fs -verbose and the result is

Checking Linux system files

The permissions on some of the files packaged by Plesk are incorrect[ERROR]

Followed by lots and lots of varied entries that include old / non-current items e.g.

WARNING: Skip checking 'plesk-milter': Cannot find deb-archive
for package plesk-milter (8.14.5-ubuntu.20.04.200703.1243)

We're on Ubuntu 24.04.2 LTS... So why is this being checked / searched for / causing a warning when it's not required or even in use?

WARNING: Skip checking 'sw-librrd': Cannot find deb-archive for
package sw-librrd
(1.6.0.3-v.ubuntu.20.04+p18.0.41.1+t220207.1604)

The same applies here ^^

WARNING: Skip checking 'plesk-php82-dba': Unable to fetch
deb-archive for package plesk-php82-dba
(8.2.27-ubuntu.24.04.241223.1519): Command '/usr/bin/apt-get
install -o Dir::Etc::sourcelist=/tmp/tmpp_tbwupi --reinstall
--download-only -y
plesk-php82-dba=8.2.27-ubuntu.24.04.241223.1519' returned
non-zero exit status 100.

This time, the Ubuntu release is correct, but PHP 8.2.* isn't active on this server and hasn't been for some time...
So, again, why is this being checked / searched for / causing a warning when it's not required or even in use?

There's many more examples, but have the constant comonality i.e. these Plesk items, shouldn't be here / being checked / shouldn't be causing this issue

f) Moving on from the previous command, to this one:

Do you want to repair incorrect permissions? [Y/n] y
Repairing incorrect permissions ................................. [FAILED]

~~~

Error messages: 1; Warnings: 0; Errors resolved: 0

Provides the expected result, which is really, just a more accurate, detailed version of the original GUI response.

None of these "errors or warnings" are causing operational issues for us, currently anyway, so there's nothing mission critcial, but they still need fixing.

So, can Plesk, can advise why this has occured, only after the upgrade to 18.0.69 (which includes mods to the process behind plesk repair fs) plus how it can be rectified?
@Sebahat.hadzhi Please can you liaise with the team and advise in due course?

Footnote, it's not related to the above AFAWK but FWIW
Plesk is custom-configured to run on many different OS's (and variations of them...) but this doesn't always see eye-to-eye with the OS itself...
EG: If we run :~# aptitude and wait for the cli / gui to load, all of the 'broken' packages that are currently being (in our case) reported, are practically ALL Plesk related (image)
We've ignored this (obviously) but sometimes / somewhere in all OS / Packages / Softeware interactions, there will be a sublte glitch that arises....

 

[Sebahat.hadzhi]

Thank you for the report. Just to make sure I have the full picture, before I forward the report to our team I would like to confirm if you have attempted clearing the packages cache?

 

[learning_curve]

Thank you for the report. Just to make sure the full picture, beofre I forward the report to our team I would like to confirm if you have attempted clearing the packages cache?

Good point - Well made @Sebahat.hadzhi
Yes, we did clear the (Ubuntu) package cache (via aptitude), twice in fact, before and after a precautionary re-boot. all 'just in case'.

However, when running this command:

apt-cache policy plesk*

There are many items in this ^ report, that remain (even after the preceding)
Some ARE installed. Some don't appear in this ^ cache even though they appear in the report incorrect permissions report. Some are NOT installed.
I'll just use the three examples from the first post (in the same order) to illustrate:

plesk-milter:
Installed: 8.14.5-ubuntu.20.04.200703.1243
Candidate: 8.14.5-ubuntu.20.04.200703.1243
Version table:
*** 8.14.5-ubuntu.20.04.200703.1243 100
100 /var/lib/dpkg/status

And

~ package sw-librrd (1.6.0.3-v.ubuntu.20.04+p18.0.41.1+t220207.1604)

^ Does NOT appear in the Plesk cache at all

And

plesk-php82-dba:
Installed: (none)
Candidate: 8.2.28-ubuntu.24.04.250411.1143
Version table:
8.2.28-ubuntu.24.04.250411.1143 500
500 Index of /PHP82_17 noble/all amd64 Packages
8.2.27-ubuntu.24.04.241223.1519 -1
100 /var/lib/dpkg/status

AFAWK Within Plesk, it's only possible to clear the nginx cache (which is effectively the apache2 cache too) by individual domain ( "Enable Nginx caching" / Click the "Clear cache" button etc ) which we have NOT yet done. Happy to do that at your request, even though it's pretty dull repeating this, domain after domain, especially when we think these specific cache's are probably unrelated to the main issue? We're not aware of any method of clearing the total 'Plesk only' cache, but again are happy to complete that, if you can provide a method to do so?

Finally, before making the intial post and FWIW we did go the whole nine yards and (just in case!) ran:

plesk repair installation

However there was no fault found / no changes made / the original issue remained unresolved.

In reality, it's a series of false positives resulting in permision warnings...

Even so, we'd like to resolve this, as for whatever reason, it's only appeared after the upgrade 18.0.69. Thanks!

 

[Sebahat.hadzhi]

I was positive you thought about that already, but had to ask just to make sure. Thank you for the confirmation. I personally don't think Nginx's cache has anything to do with that. We have a similar bug logged for another package (PPPM-14437). I have now forwarded the details to our team and I will keep you posted. I hope they will figure out a way to reproduce the issue, because I was unable to do so. If they can't, we will likely need access to the server.

 

[alvarezcruz]

Hi there, Can you please run this to see if any of these are duplicated?

dpkg -l | grep -E "plesk-php82-dba|plesk-milter|sw-librrd"

Looking at the version numbers, it looks like the system didn't remove some old packages correctly and the duplicates aren't actually installed, but are still marked as installed, which makes the repair tool fail to do anything to them because they're not there.

 

[learning_curve]

dpkg -l | grep -E "plesk-php82-dba|plesk-milter|sw-librrd"

Sure. Here's the output:

# dpkg -l | grep -E "plesk-php82-dba|plesk-milter|sw-librrd"
ii plesk-milter 8.14.5-ubuntu.20.04.200703.1243 amd64 Sendmail Mail Filter API (Milter)
rc plesk-php82-dba 8.2.27-ubuntu.24.04.241223.1519 amd64 A database abstraction layer module for PHP applications
ii sw-librrd 1.6.0.3-v.ubuntu.20.04+p18.0.41.1+t220207.1604 amd64 RRDtool libraries

 

[learning_curve]

@alvarezcruz Your comment:

...the system didn't remove some old packages correctly and the duplicates aren't actually installed, but are still marked as installed, which makes the repair tool fail to do anything to them because they're not there.

Is a more accurate version of our previous assumption:

...In reality, it's a series of false positives resulting in permission warnings...

In the case of the three examples from your output request:

plesk-milter 8.14.5-ubuntu.20.04.200703.1243 ~ is shown as "ii" which matches its state in the apt-cache policy plesk* return

sw-librrd 1.6.0.3-v.ubuntu.20.04+p18.0.41.1+t220207.1604 ~ is also shown as "ii" which is odd, as it's not present in the apt-cache policy plesk* return

plesk-php82-dba 8.2.27-ubuntu.24.04.241223.1519 ~ is shown as "rc" which 'technically' matches its state in the apt-cache policy plesk* return, in that, it's removed / uninstalled but the config files still remain

The codes (when using dkpg -l)

First letter → desired package state ("selection state"):

• u ... unknown
• i ... install
• r ... remove/deinstall
• p ... purge (remove including config files)
• h ... hold

Second letter → current package state:

• n ... not-installed
• i ... installed
• c ... config-files (only the config files are installed)
• U ... unpacked
• F ... half-configured (configuration failed for some reason)
• h ... half-installed (installation failed for some reason)
• W ... triggers-awaited (package is waiting for a trigger from another package)
• t ... triggers-pending (package has been triggered)

Third letter → error state (you normally shouldn't see a third letter, but a space, instead):

• R ... reinst-required (package broken, reinstallation required)

 

[alvarezcruz]

Was there only one result of each, or were there multiple lines? Please share the output of the command, if possible.

 

[learning_curve]

Was there only one result of each, or were there multiple lines? Please share the output of the command, if possible.

Yes. There is only one result of each. Post #6 is the complete output of the command

 

[alvarezcruz]

Oh my bad, sorry, I'm at work too and missed that one entirely. So these are 2 package from Ubuntu 20.04 and one that was removed but kept the config files. Sounds like none of them should be there. Why don't you try removing them? Should be without dependencies, with a command like this one:

dpkg -r --force-depends "packagename-version"

For the one that is already removed, try apt purge plesk-php82-dba

and by the way, was this server upgraded or migrated from an older version of Ubuntu?

 

[learning_curve]

@alvarezcruz

Edit: We were almost at cross messgaing then

Initially, we could...
Manually remove all of the Non-Ubuntu 24.04.* LTS items that are shown in the plesk repair fs -verbose output (example shown)
If we've understood this correctly, this would not have any detrimental effect on server performance as these would all be 'old/not-required packages/records'
This will take some time though...

# apt purge plesk-php82-dba
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
plesk-php82-dba*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]

 

[alvarezcruz]

Yeah, it would take some time. We could write a little scripted command to do it automatically. Are you okay with posting the entire output of repair fs?

 

[learning_curve]

~ So these are 2 package from Ubuntu 20.04 and one that was removed but kept the config files. Sounds like none of them should be there. Why don't you try removing them? Should be without dependencies, with a command like this one:

dpkg -r --force-depends "packagename-version"

For the one that is already removed, try apt purge plesk-php82-dba

Yes. We'll run backups / snapshots etc / do this in due course and update this post

and by the way, was this server upgraded or migrated from an older version of Ubuntu?

It was originally a fresh Ubuntu 20.04 LTS setup, then it's progressed (via the Plesk Dist-Upgrade process) from 20.04 LTS > 22.04 LTS > 24.04 LTS (current)

 

[alvarezcruz]

Thank you, then it makes sense that during the dist-upgrade process some packages were left over. Minor glitches during those process can cause such issues.
Very well, let me know if you want help with automating that. Otherwise, I look forward to the result.

 

[learning_curve]

Yeah, it would take some time. We could write a little scripted command to do it automatically. Are you okay with posting the entire output of repair fs?

Sure. Happy to use a scripted command if you're willing to provide one.
We'll send the entire output in a .txt file to you via PM
Please confirm if you require the output from plesk repair fs - OR - plesk repair fs -verbose

 

[alvarezcruz]

Either one is okay as long as it lists the deb files. I don't need any other info besides that. Just give me some time for the command, as I have some tasks at work at the moment.

 

[alvarezcruz]

Thank you, I received the output. Some of the packages on the list are very sensitive. I would still try to remove them, but first I'd create a server snapshot with the hosting provider, so I can easily roll it back in case this takes the server down.

Please listen to the warning above. I have no access to your server, so I can't guarantee this will have the intended effect.

This command will get the list of packages from the repair utility:

plesk repair fs -n -verbose | grep "deb-archive for package" | tr -s ' ' | cut -d' ' -f5

If you see that they are parsed correctly, you can run this one to remove them all without dependencies in a loop:

for package in $(plesk repair fs -n -verbose | grep "deb-archive for package" | tr -s ' ' | cut -d' ' -f5); do dpkg -r --force-depends $package; echo "$package has been uninstalled without dependencies"; done

If this does take the server down, then maybe some of them need their newer versions installed. In that case, I'd restore the snapshot and check one by one.

 

[learning_curve]

Thank you @alvarezcruz It's now complete. All problems resolved. No server was taken down in the making of this post

This:

plesk repair fs -n -verbose | grep "deb-archive for package" | tr -s ' ' | cut -d' ' -f5

Ran smoothly and parsed all

for package in $(plesk repair fs -n -verbose | grep "deb-archive for package" | tr -s ' ' | cut -d' ' -f5); do dpkg -r --force-depends $package; echo "$package has been uninstalled without dependencies"; done

This also ran smoothly but there were lots of refusals as well as the items removed.

We rectified all of the items by way of:

apt purge plesk-php82 plesk-php82-bcmath

plus all the other plesk-php82 records

Then

apt autoremove --purge plesk-milter

For any remaining items that were refused and were not just configuration data only

After all of this ^^
We ran all of the Ubuntu checks, cleans and updates - No problems at all.

We then ran the Plesk panel/GUI process:

/modules/repair-kit/index.php/index

No problems with anything at all.

For completeness, we then ran CLI:

plesk repair all -n

Again, no problems with anything at all.

A final re-boot - just in case ...
But all is good. No issues remain.

So thanks again for the assist @alvarezcruz Much appreciated

@Sebahat.hadzhi This can be changed to resolved now thankfully!
Some quick thoughts FYI: It appears that these changes in 18.0.69:

The plesk repair fs command can now fix permissions and ownership of certain files related to the server’s mail system (for example, /var/lib/plesk/mail/handlers). (PPPM-14907)

Are acting very positively, not potentially negatively (as first suggested in our opening post) but ironically, they are now exhibiting what appears to be, a poor clean-up process from both the Plesk removal process (the PHP 8.2 configuration data in this case) and/or OS Dist-Upgrades conducted via Plesk. Neither of these, are critical or result in service failures, so none are urgent, but it maybe useful data for the Plesk Team to able to improve these for future use.

 

[alvarezcruz]

Excellent to hear that worked out. Yes, I forgot that some were removed and only had the config files left. I'm glad you sorted it out and everything is working well now.

Adding to your last statement; Plesk doesn't carry out the dist-upgrade, the OS does. The Plesk scripts and guides are just to prepare Plesk for the dist-upgrade process carried out by the system. It's likely that it had some issue which led to both the old and improperly removed packages. It may be worth inspecting the package manager on the system.

 

[learning_curve]

~~ Plesk doesn't carry out the dist-upgrade, the OS does. The Plesk scripts and guides are just to prepare Plesk for the dist-upgrade process carried out by the system.

You're correct, again!
Albeit IF you're using Plesk, then in order to run an OS Dist-Upgrade, the only choice you have (really) is via this Plesk article i.e use these scripts only, in order to prevent an OS Dist-Upgrade from making any changes, that would have an adverse effect on Plesk. That's fair enough, but this does add scope for errors...

Meanwhile... IF you run an OS Dist-Upgrade without Plesk i.e. on a server where Plesk is not present, it's much simpler (as no Plesk compliance / interaction is required). This way (unless custom configs have been added that don't fit well with a OE OS Dist-Upgrade) it usually work well & normally, there's no residue.

It's likely that it had some issue which led to both the old and improperly removed packages. It may be worth inspecting the package manager on the system.

Yep, agreed. No real idea when it happened, but we're happy with the package manager on the system now. It's easy to manage (apart from the Plesk items ) by using both Aptitude and/or the various commands available via Apt. FYI some time ago (but not related to this) we did add this suggestion to take care of any residue, post any Plesk (not OS) upgrades. It's not gathered any steam yet, probably, because many users haven't looked at how much "old / non-current" Plesk data is still taking up server real-estate, so it's not not important. There's still no automatic detailed clean-up, after a Plesk Obsidian release, upgrade AFAWK.