error from domain wrapper SUBDOMAIN DOES NOT EXIST FOR USER (solution)

[Metro2]

I hope this information helps other hosts out there who might be encountering the same kind of issue....

So I ran into a problem trying to remove a subdomain from one of my customer's cPanel.

If I went to cPanel > Subdomains and clicked the "Remove" link next to the subdomain in question, cPanel would just spit back this message:

"error from domain wrapper: subdomain does not exist for user"

So then I checked WHM > List Subdomains to check for duplicates / incorrect users or anything else suspicious, but nothing unusual there.

Below is what I did to FIX the issue and had no problems with it, but I can't say whether it's the best way. I'd recommend getting a second opinion or maybe someone else can post their thoughts on the method I used.

(Note - since the subomains were actually part of an addon domain under the master user account, and he was running a "twitter" subdomain and a "blog" subdomain, I should explain that in the commands below "username" is the master account user and "example" is an addon domain and twitter / blog are the subdomains I discovered "stuck" in his folder in /var/cpanel/userdata/ )


Here's what I did:

ssh into the server and login to root

grep -r twitter.example.com /var/cpanel/users (found nothing there)

so then i checked:

grep -r twitter.example.com /var/cpanel/userdata (and came up with several hits to start examining)

removed the following files:

rm /var/cpanel/userdata/username/example.username.com.cache

rm /var/cpanel/userdata/username/blog.example.com.cache

rm /var/cpanel/userdata/username/twitter.example.com.cache

rm /var/cpanel/userdata/nobody/twitter.example.com

rm /var/cpanel/userdata/username/twitter.example.com

rm /var/cpanel/userdata/nobody/twitter.example.com.cache

Then I EDITED /var/cpanel/userdata/username/main and removed twitter.example.com from it

Then I logged into WHM > cPanel > Upgrade to Latest Version and simply ran update. I did this last step in hopes that everything was resolved and for the most part it was, but there was some lingering "DocumentRoot" missing warnings in the logs during httpd restarts, and so one last step was needed:

Then ran /scripts/rebuildhttpdconf and it finally removed the bogus domain virtual containers from httpd.conf

Ran cPanel update once more and the problem is gone.

I'm interested in any opinions / comments or perhaps anything I've missed, but hopefully this helps someone. I'm sure I took the long-route but it worked.

 

[cPanelTristan]

I would advise personally to not remove data and those cache files would not have needed to be touched. Here are what I would suggest doing:

[Of note, all iterations of sub.domain.com represent the subdomain name, while all those of username represent the cPanel username]

grep sub.domain.com /var/cpanel/users/*
grep sub.domain.com /etc/*
grep -R sub.domain.com /var/cpanel/userdata/*
grep sub /var/named/domain.com.db

If you find any entries, then make a backup of the file before editing it:

cp /var/cpanel/users/username /var/cpanel/users/username.bak110721
cp /var/cpanel/userdata/username/main /var/cpanel/userdata/username/main.bak110721

For the sub.domain.com file in /var/cpanel/userdata/username location, simply move it entirely (since it cannot be edited and has to be moved out of the way):

mv /var/cpanel/userdata/username/sub.domain.com /var/cpanel/userdata/username/sub.domain.com.bak110721

If you find the domain listed in /etc/localdomains and/or /etc/userdatadomains locations, then move /etc/localdomains file and run /scripts/updateuserdomains:

mv /etc/localdomains /etc/localdomains.bak110721
/scripts/updateuserdomains

For userdatadomains, if it has been properly removed from all the other above locations, then you should update the cache to update that file:

/scripts/updateuserdatacache

Finally, for the DNS zone if the subdomain exists in it, edit that in WHM > DNS Functions > Edit DNS Zone to remove the subdomain there.

At that point, re-run the grep above. If the domain doesn't show in any of the files other than the backups made, then run these commands to update /usr/local/apache/conf/httpd.conf if there were entries in /var/cpanel/userdata/username location:

cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf
/scripts/rebuildhttpdconf
/etc/init.d/httpd restart

At that point, check the subdomain isn't in /usr/local/apache/conf/httpd.conf location:

grep sub.domain.com /usr/local/apache/conf/httpd.conf

If it is gone from there, you should not see it on the account any longer.

 

[cpGuest]

Hi, cPanelTristan. Thanks for your instructions, I've completed iterations that you suggested trying to wipe out bad configured addon domain. Every grep from your list returns empty result, except one:

grep mysubdom /etc/*
Binary file /etc/userdatadomains.stor matches

Could you please explain what is the userdatadomains.stor and how to rebuild it? It seems some traces are still exist, because when I try to add this domain mysubdom.com I got cPanel error:

Error from domain wrapper: mysubdom.mydomain.com is owned by another user.

I haven't see it nor in cPanel Addon domains list, nor in WHM Subdomains list though. Maybe you can suggest another files I should check/delete/change ownership (I log into cPanel with user different from root, maybe this matters)?

 

[cPanelTristan]

Did you try running /scripts/updateuserdatacache from command line? If so, and the issue is still happening, then I would suggest opening up a ticket in WHM > Support Center > Contact cPanel or using the link in my signature. Please post the ticket number here upon submitting it.

 

[cpGuest]

Yes, I tried /scripts/updateuserdatacache several times under root account via SSH. I submitted ticket number 1762425, thank you.

 

[cpGuest]

Thank you all, problem resolved. The problem was because for addon domain there are two corresponding zone files involved, I checked only /var/named/mysubdom.com.db but there were still entries for the subdomain in the zone file of main domain at /var/named/mydomain.com.db.

 

[cPanelTristan]

This is why above I shortened it to sub rather than sub.domain.com in this command:

grep sub /var/named/domain.com.db

You have to grep for the sub portion of the subdomain (so happy if you have happy.mydomain.com) in /var/named/mydomain.com.db file.

 

[Metro2]

Tristan - thank you very much for taking the time to follow-up on this and provide a more correct / sound method of handling a situation like this. There really isn't much proper documentation at all on this topic (error from domain wrapper SUBDOMAIN DOES NOT EXIST FOR USER) on the web nor what to really do about it up until now that this thread exists. Although my method did seem to work for me, obviously it was primative and there was a better way as you have pointed out in detail. I think this information will be useful to many more hosts than anyone would expect. Thank you!

 

[gkgcpanel]

Had a similar problem where the user removed the addon domain and tried to re-add it. It kept failing with a generic "Can't add this addon domain because it already exists".

I checked and it was removed from all files except /var/cpanel/userdata/USERNAME/main.

Copying this file to a bak file and removing it, and then running /scripts/rebuildhttpdconf solved the problem.

The customer can now add the addon domain again.