Adding zone changed ownership of /etc/userdomains

[jndawson]

We added a stand-alone zone, that is, a zone not attached to any account. Apparently, the action changed the ownership of /etc/userdomains from root:mail to root:root. Mode was not changed.

We only discovered it because customers suddenly started complaining about bounces:

The message could not be sent. The setting for your outgoing email [SMTP] server might need to be configured. To find the server settings for '[email protected]', please contact your email service provider.
Subject 'Re: Subject'
Server Error: 451
Server Response: 451 Temporary local problem - please try later
Server: 'cp1.anotherfakedomain.tld'
Windows Live Mail Error ID: 0x800CCC79
Protocol: SMTP
Port: 465
Secure(SSL): Yes

Looking in the logs:

2016-04-27 14:26:25 H=111.222.333.444.static.fakedomain.tld (ICRPC) [111.222.333.444]:33889 X=TLSv1:DES-CBC3-SHA:168 CV=no F=<[email protected]>
A=dovecot_login:[email protected] temporarily rejected RCPT <[email protected]>: failed to expand ACL string "${if eq{${lookup
{$sender_address_domain}lsearch*{/etc/userdomains}{$value}}}{$sender_address_local_part}{1}{0}}": failed to open /etc/userdomains for linear
search: Permission denied (euid=47 egid=12)

Changing ownership back to root:mail fixed it.

1. Is that a known issue?
2. Is there a way to prevent that?

 

[cPanelMichael]

Hello

Internal case CPANEL-5899 is open to address this issue. I will update this thread with more information on the status of this case as it becomes available. In the meantime, you can run "/scripts/updateuserdomains" after adding the zone to correct the ownership values on /etc/userdomains.

Thank you.

 

[jndawson]

Hello

Internal case CPANEL-5899 is open to address this issue. I will update this thread with more information on the status of this case as it becomes available. In the meantime, you can run "/scripts/updateuserdomains" after adding the zone to correct the ownership values on /etc/userdomains.

Thank you.

Thanks.

 

[tiagorf]

Thanks.

We are having the same problem on multiple servers since the upgrade to WHM 11.56.0.9
This is creating alot of issues, as our clients stop receiving and sending emails while we don't correct the ownership.

Is there a script like postcpbackup for a zone creation? This could help create a temporary fix.

 

[WebHostPro]

I just got this today as well. Is there a way to prevent this from happening in the future yet? We add a lot of stand alone zones for servers with no local DNS.

It just started after the last CPanel WHM 56.0 (build 9) update this morning.

 

[cPanelMichael]

Hello,

The resolution to this issue is included in version 56.0.13:

Fixed case CPANEL-5899: Cpanel::FileUtils::Modify does not preserve group ownership.

You can update to the new version via "/scripts/upcp" over the command line, or through Web Host Manager (WHM Home >> cPanel >> Upgrade to Latest Version).

Thank you.

 

[jandafields]

I had the same problem today on a test server, on Edge.
(installed on May-29-2016 and then immediately updated to Edge)
Version 57.9999 (build 62)

Running /scripts/updateuserdomains fixed it.

 

[cPanelMichael]

I had the same problem today on a test server, on Edge.
(installed on May-29-2016 and then immediately updated to Edge)
Version 57.9999 (build 62)

Could you verify the specific steps you are taking to reproduce the issue? I've been unable to reproduce this on cPanel 57.9999.69 after manually creating a DNS zone via Web Host Manager and through WHM API 2.

Thank you.

 

[jandafields]

I did try to reproduce it, but was unable to do so after I ran updateuserdomains.

Basically, I installed, updated, created an account, changed and added several DNS entries, and then after that I noticed there was that problem. I found this thread, ran the updateuserdomains commaned, and it was fixed then. I then tried to reproduce it, but I could not. It must be some combination of things. I was running NSD, not BIND, I don't know if that had anything to do with it or not.

 

[cPanelMichael]

When referring to this problem, are you referencing the permissions on the /etc/userdomains file, or do you mean you noticed the "Server Response: 451 Temporary local problem - please try later" message during email activity? I've tried several methods of reproducing this issue with both Bind and NSD, but have been unable to do so. It's possible this was a temporary issue unrelated to the previously reported issue in this thread.

Thank you.