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 -
Hi,
Are you using an NFS volume for your backups? Because I do, and it cause me the same error. cPanel says that they don't support NFS for backups (didn't knew that, but hey! RTFM), but it was working before the migration to version 136. At least cPanel should ensure that their new version don't break existing installation. My 2 cents.
0 -
Same problem here and using NFS also.
0 -
If these issues are all on NFS systems that's likely the problem, as that isn't an architecture we currently support.
0 -
The problem is with permissions of the parent directory "userdata" and "scope".
If I do this I get:
[root@dedicado3 ~]# chmod 755 /backup/2026-06-26/accounts/sistemas/userdata/scope
chmod: cannot access '/backup/2026-06-26/accounts/sistemas/userdata/scope': Permission deniedif I change permission to 755 on userdata, then I can change scope's and create a directory on it:
[root@dedicado3 ~]# chmod 755 /backup/2026-06-26/accounts/sistemas/userdata/
[root@dedicado3 ~]# chmod 755 /backup/2026-06-26/accounts/sistemas/userdata/scope/
[root@dedicado3 ~]# mkdir /backup/2026-06-26/accounts/sistemas/userdata/scope/testit works.
0 -
I think it's a bigger issue, on our support ticket, there is a CPANEL-xxxxx created, so I hope they will fix it soon.
0 -
Eve Vahter - can you share that full case number or your ticket number? Those aren't top secret.
0 -
At this time our team is currently working on the new case with ID: CPANEL-53964.
0 -
Same on my side. I did a test and removed the scope directories from all /var/cpanel/userdata/USERNAME/. As soon as I did that, the backups worked, even on NFS. The issue is likely due to pkgacct. And it started as soon as cPanel went to version 136.
1 -
Yes, clean them, but the next day they are back, at least some of them. So it's not a solution. So, I need to fix it. It was 136 update it started, I can confirm that.
0 -
Thanks for that - that case does seem to match up with what is happening here.
We should have this issue resolved in the next update. I've linked this thread to the case so I'll be sure to post an update once I have one.
0 -
Glad I have somebody that can confirm my findings.
0 -
I would also suggest making
pkgacctmore tolerant of non-critical errors. In many cases, a partial backup is far more useful than having the backup process fail entirely or produce a corrupted archive.0 -
Here's 2 articles somewhat related to the problem
Ticket CPANEL-50845
Ticket CPANEL-53207
0 -
Those wouldn't be related to this issue at all. It's also important to note those are our internal case number and not customer ticket numbers.
0 -
I confirm that running this before backup:
find /var/cpanel/userdata/ -type d -name "scope" -exec chmod 755 {} \;solves the problem.
0
Please sign in to leave a comment.
Comments
30 comments