Transfer issues - new server not allowing addon domains
Hello,
We ran into an intermittent transfer issue... not always happening. This involves transferring accounts with Addon domains to a new server... both using the same DNS Only cluster.
What is happening is that the Addon domains are not being restored to the new server because the related sub-domain is failing to be restored.
For example, one of the error lines is:
Failed to restore the domain “test.****.****.com”: Restoration of “test.****.****.com” will be skipped because it requires that “test.****.****.com.****.****.com” be created before it can be restored.
So the subdomain was not created, therefore the add-on domain could not be restored.
What I need to know is where is the conflict? This is not always happening.
To fix the problem, we have to first remove the DNS zone for that add-on domain, and then add it manually to the account on the new server. You cannot just add it, as the DNS zone exists. Yes, the new IP is there, but again... the domain itself cannot be added since there already is a DNS zone.
-
We had the same issues recently.
If the add-domain uses the default web root for non shared content it fails.
Eg. Add newdomain.com into otherdomain.com.
Choose not to share the web root and cPanel will set the home directory to.
/home/user/newdomain.com
As soon as there is a fullstop in the subdomain it fails to restore (.)
It took a while to clean up and get it restored manually.
We weren't using servers in the same cluster but the addon domain was added to DNS but not restored.
I don't know where to send the transfer logs to here so that it can be fixed.
0 -
This is a known bug. Please ensure you have the latest cPanel version installed.
Andrew N. - cPanel Plesk VMWare Certified Professional
Do you need immediate assistance? 20 minutes response time!*
EmergencySupport - Professional Server Management and One-time Services0 -
It was the latest version on the target server, but it's a known issue.
Using the live transfer option is where the issue appeared for us.
It was the manual backup and restore plus some DNS zone wizardry that got us sorted.
Thankfully we had only around 20 accounts affected.
Would be nice to see a tool that can swap an an addon domain to the primary domain in the future.
0 -
First... WHY would a primary domain ever be parked under a sub-domain? Then it's not the primary domain... it's an add-on domain... so I am not getting that at all. I am also not speaking of moving an add-on domain to be the primary domain... if that needs clarification.
But let's leave that for a moment as... I am referring to moving an account to another server, and the add-on domains not being properly restored. The DNS is moved OK, but the add-on domain comes up with errors.
E.g.Restoration of “addon.ca” will be skipped because it requires that “addon.ca.primary.ca” be created before it can be restored.Prerequisite domain, “addon.ca.primary.ca” is not referenced in the restore file and does not preexist.
I understand that add-ons first require a subdomain of the primary to be created. Question is, why was it not created? The Product and Feature settings are all correct and allow for subdomains.
Please correct me if I'm wrong here, as I may have just discovered what the issue is, or at least what MY issue is:
There are two settings in TWEAK... and I'm thinking the second one is new?1) Restrict document roots to public_html
- we always use separate folders OUTSIDE of /public_html (same level rather than below) for add on domains... so that is switched OFF
2) Share the document root by default when creating a domain
- is this a NEW setting? This would really mess up a restore during transfer if the add-on domains originally had their own folders (same leve as /public_html), would it not? It's contrary to No. 1 to, is it not?
So if I switch No. 2 to "Off", I'm thinking that solves the problem?0 -
This is a known issue that you can find more details on here:
https://support.cpanel.net/hc/en-us/community/posts/19630209043095
We're working on getting that fixed soon!
0 -
OK, thank-you.
So this has nothing to do with my no. 2 reference above?0 -
Correct - adjusting either of those values you found will not change this behavior.
0
Please sign in to leave a comment.
Comments
7 comments