"You don't have permission to restore user bob"

[dingham]

"You don't have permission to restore user bob" - Fixed

Hi Guys,
One of our resellers has been trying a slow migrate, backing up users on the live server & restoring to the new, using the DA backup & restore features.
Of ~60 users, 3 have just thrown out the above error.

reseller: bill
user: bob

[root@bill user_backups]# ls -l bob.tar.gz 
-rw-r----- 1 bill bob 233766003 Sep 25 05:29 bob.tar.gz

Subject: An error occurred during the restore. Today at 05:32
You don't have permission to restore user bob

The odd thing is that the permissions are the same as all the other users (bar the GID), which restored perfectly fine.

Ideas?

Fix: untar the file manually & retar it with gnutar or, update gnutar.
http://www.directadmin.com/forum/showthread.php?t=20814

 

[DirectAdmin Support]

Hello,

The error:
You don't have permission to restore user bob

means that the system account bob exists on your system, but the user is not in your:
/usr/local/directadmin/data/users/reseller/users.list
file.

If there is no folder:
/usr/local/directadmin/data/users/bob
Then bob has not yet been added into DA, so delete the system account before restoring:

userdel -r bob

if the folder bob does exist, then bob has been added into DA.. either under some other reseller account (check to see who) or else "bob" is simply missing from your users.list file, so add "bob" to that file, then restore normally.

John

 

[dingham]

ok, well that at least adds the user to the list. Presumably we can copy everything over manually?

I deleted the user & it's related articles, it's group & anything else to do with it, left over; Ran restore, which created the user, group & all base files/directories; added the user to users.list & ran a 2nd restore, in the hope the remaining data would be copied over.
Unfortunately, the new data wasn't copied over & I've been left with just the user's base directories.

Whilst we can copy everything over manually, this is rather bizarre. Can you share any insight as to what you think might have started the problem in the first place?
There were no files within the user's directory with unusual ownership or permissions, and afaik, it was no different from the other 60 users that restored successfully.

Cheers,

 

[DirectAdmin Support]

I'm not too sure.. could be a few possible reason (just guessing here).
- If the dataskq is shut off prematurely, any reason.. memory limit, server shutdown/reboot, manual killing of the process..
- the users.list gets a lock on it, so if the page is being used in DA while the account is being restored at the same time (talking split seconds here) then it could cause the user not to be in the list.. but the data would still have been present if that were the case.

John

 

[dingham]

Hi John,
Thanks for the pointers.

In the end, it turned out to be a discrepancy between bsdtar & gnutar.
It's actually a documented bug in gnutar (fixed as of v1.19), whereby it gives the wrong exit status when it can't read the complete file headers.

Fix: untar the file manually & retar it with gnutar or, update gnutar.

After I had worked it out, I noticed this has been seen before: http://www.directadmin.com/forum/showthread.php?t=20814