I tested it on CentOS and I'am not able to trick the ispconfig 3.0.4.x updater to enable both plugins, so I can not reproduce this on current versions. The only option that I can think of is that someone tried a downgrade of ISPConfig on the server so that the updater from a ISPConfig version < 3.0.4 (e.g. 184.108.40.206) was run on a server again that was updated to ISPConfig > 3.0.4 already.
In your case, several things came together in a combination which is not common for a ISPConfig setup plus that there must have happened some kind of ISPConfig software downgrade attempt which explaines why no other users had this problem yet.
A server where nginx and apache are installed at the same time. This is a combination of services that is not used by ISPConfig normally and does not exist as ISPConfig perfect setup guide. ISPConfig uses either nginx or apache but not both. Nevertehless we took care of this situation in the installer and updater of ISPConfig > 3.0.4 so that not both plugins were activated at a time.
The problem itself is caused by the fact that the client of the website was changed and the nginx and apache plugins were both enabled. So both plugins tried to do the same thing after another, they moved the website from the old path to the new path on the harddisk and that failed for the second plugin as the site was moved already to the new location.
I will add a check in ispconfig that checks at runtime and not just in the installer and updater that ensures that not both plugins are enabled.
Last edited by till; 19th January 2012 at 16:21.