If you’re trying to package a cPanel account on the command line and you’re hitting and error that looks something like this:
Copying SSL certificates, CSRs, and keys...Privilege de-escalation before loading datastore either failed or was omitted. at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1159 Cpanel::SSLStorage::_load_datastore('Cpanel::SSLStorage::User=HASH(0x4743200)', 'lock', 1) called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1244 Cpanel::SSLStorage::_load_datastore_rw('Cpanel::SSLStorage::User=HASH(0x4743200)') called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 329 Cpanel::SSLStorage::_rebuild_records('Cpanel::SSLStorage::User=HASH(0x4743200)') called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 308 Cpanel::SSLStorage::__ANON__() called at /usr/local/cpanel/Cpanel/AccessIds/ReducedPrivileges.pm line 85 eval {...} called at /usr/local/cpanel/Cpanel/AccessIds/ReducedPrivileges.pm line 85
Check to make sure that the account’s files are owned by correct user and group, using these commands (be sure to replace the paths with the paths on your server).
ls -l /path/to/user/homedir/
If your output looks something like this:
lrwxrwxrwx 1 1037 1034 34 Jun 12 20:46 access-logs -> /usr/local/apache/domlogs/USER/
-rwxr-xr-x 1 1037 1034 33 Jun 26 2009 .bash_logout*
-rwxr-xr-x 1 1037 1034 176 Jun 26 2009 .bash_profile*
-rwxr-xr-x 1 1037 1034 124 Jun 26 2009 .bashrc*
-rwxr-xr-x 1 1037 1034 24 Jun 26 2009 .contactemail*
drwxr-xr-x 3 1037 1034 4096 May 7 2011 .cpaddons/
drwx------ 5 1037 1034 4096 Jun 12 20:46 .cpanel/
-rwxr-xr-x 1 1037 1034 1 Jun 27 2009 cpbackup-exclude.conf*
If the account exists on your server, you should be able to run this command (make sure to replace user.user with the appropriate account username on your server):
chown USER.USER -R /path/to/user/homedir/ If you get an error about the user not being valid, that means the user doesn’t exist on the system.
Try running this (make sure you replace the numbers in the string with the numbers in the user/group columns from your output):
egrep '1034|1037' /etc/passwd /etc/group /etc/shadow
If you don’t see anything that reflects a user with the user:group of those UIDs, then the problem is simply this: the files are owned by a user that doesn’t exist on the system. If you migrated or restored this account, terminate it and recreate it.
If you didn’t migrate or restore the account, you’ll want to figure out why the account went away and recreate it. If you are unsure about how to do that, I recommend finding a sysadmin to help you, as a mistake in those steps could be catastrophic to your system.