Permission denied at bin/pkgacct.pl line 2037
Hi,
Since the last update to 136, I'm getting problems for my backups.
These are the error I get in my log, fresh from this morning :
Copying proftpd file....[2026-06-07 02:02:28 -0400] Done
[2026-06-07 02:02:28 -0400] Copy userdata...[2026-06-07 02:02:28 -0400] mkdir /backup/2026-06-07/accounts/USER/userdata/scope/inproductsurvey: Permission denied at bin/pkgacct.pl line 2037.
[2026-06-07 02:02:29 -0400] warn [backup] (XID y9jh7v) “/usr/local/cpanel/bin/pkgacct” reported error code “1” when it ended:
I have 3 servers running 136, and the problem is present on all 3 servers. And just to be clear, the problem seems random. Some accounts would fail one day, but not the other. And doing the backup manually on CLI works, I tried it.
-
Hey there! Usually when this error happens it's because the backup directory has the wrong ownership, causing problems to the automated script.
Can you ensure that the main /backup directory and all its contents are root:root ownership on the filesystem?
0 -
Hi!
Thanks for your reply.
I checked, and on all 3 servers the ownership of the /backup directory is
This ownership was not changed by myself. Could it have been changed by the backup process?
0 -
Thanks for that information. Usually when something is owned by a number that indicates there is a process that ran at some point. Maybe these servers were restored from an image or the backup drive was replaced as part of routine maintenance?
I don't have a good explanation on my end for that change as cPanel tools wouldn't change the ownership of that directory.
0 -
Hi,
Thanks for your reply.
Okay, so in order to solve my problem, I'd need to change the ownership of the directory to root:root? And everything would works after that? As I said, the problem seems random : some clients got the error, some don't, and not always the same ones.
Thanks.
0 -
I would run this exact command on the system in order to ensure you permanently resolve the error:
chown -Rf root:root /backup
0 -
Hi,
All right, I made the change. I'll wait when the next backup run to see if the problem is solved.
I'll keep you posted.
Thanks.
0 -
Sounds good - let me know!
0 -
Hi!
The problem occurs again last night.
And the permissions for the /backup directory got set back again to
I'm starting to suspect the backup process in in cause.
0 -
So the ownership on the directory itself was changed even after that command was run? I'm not sure of anything that would do that on our side.
Are you using the standard cPanel backup tool on this machine?
0 -
Hi,
Yes, I am using the standard cPanel backup tool. The "100 users" owner is the standard owner for backups directories. Hence my suspicion of the change of ownership by the backup tool. There is definitely something going on.
0 -
Hi,
Same problem this morning. There is definitely something broken with the backup tool. Is there a way to open a ticket with cPanel for this issue?
0 -
Who you open the ticket with would depend on where your license is purchased, but you can start from WHM >> Create a Support Ticket and go from there!
0 -
Hi,
Will do. There is a new version of cPanel release today. Maybe the problem will be solved with this new release.
0 -
I doubt it, as this isn't an issue we can reproduce on our end. At this point we really need to see the server in question to determine what is happening.
0 -
We're seeing the same issue on a production server after updating to cPanel 136.
Environment:
cPanel/WHM 136
Standard cPanel backup system
Issue started only after the update
Rebooting the server did not resolve it
The backup log contains repeated errors such as:
Copy userdata...
mkdir .../userdata/scope/inproductsurvey: Permission denied at bin/pkgacct.pl line 2037.
warn [backup] "/usr/local/cpanel/bin/pkgacct" reported error code "1" when it endedThe failures occur during the Copy userdata phase and always reference:
userdata/scope/inproductsurvey
Interestingly:
The problem affects many accounts, but not always the same accounts.
Manual pkgacct runs can succeed.
The issue persists after reboot.
We initially suspected the backup destination, but identical reports appear from servers using local /backup storage.
The error is very similar to the known scope directory issues described in CPANEL-50845.
Can anyone from cPanel confirm whether this is a known regression in v136 related to the new scope/inproductsurvey userdata structure?
Also, are the generated account backup archives considered valid despite pkgacct returning exit code 1 and WHM reporting the accounts as failed?
Thanks.
0
Please sign in to leave a comment.
Comments
15 comments