Error during Admin Backup after upgrading to DirectAdmin v1.650

Aspegic

Aspegic

Verified User
Joined
Aug 4, 2005
Messages
282
I did search, a lot, and found several threads that deal with Backup problems, but non that seem to be the same as the problem I'm having.


This server has been running perfectly for the past 2 years.
Nothing changed on the server recently that could account for this error (except if it is related to the DirectAdmin upgrade).


1687425483697.png

The error is the same each time:

Code: 
User academy has been backed up. <2:22:48>
User cbtv has been backed up. <2:22:58>

Error Compressing the backup file /home/admin/admin_backups/colorbase/backup/home.tar.gz : /bin/tar: c\:\temp\\junk.txt:
Cannot stat: No such file or directory
/bin/tar: Exiting with failure status due to previous errors

<2:25:18>
User dev has been backed up. <2:26:55>
User live has been backed up. <2:26:55>

There is more than enough disk space available for the backup, so that's not the problem.
It's also not a problem of access rights, I checked that.

What seems odd, is this part of the error message: "c\:\temp\\junk.txt" <-- that looks like a Windows' path to me. Why would that show up on a Linux machine?

The server is running Centos 7 (Yep, I know v7 will be deprecated, this machine is to be decommisioned at the end of this year, but it still needs to last the coming 6 months).

I hope someone can help me with this ?
 
Last edited:
Aspegic said:
What seems odd, is this part of the error message: "c\:\temp\\junk.txt"
Click to expand...
This catched my eye instantly too, but it's during the backup of the home.tar.gz which means for some reason it's looking for this somewhere in your (admins) home directory.
Have you check all files and directory's in you home (so also under Maildir, backup, public_html and subfolders, so everywhere) for odd entries or strange files?
 
Hi Richard, thanks for replying.

Yes, I have checked that, but nothing. I also checked the rkhunter log, nothing there either.
I also specifically looked for a file named junk.txt, but it does not exist anywhere on the server.
I even searched all files if one contains the text "junk.txt", but nothing.

The backup process does create a backup-file for the account, which looks more or less the correct size. But by that time all the temp-files/directories that are created during the backup process have already been deleted.

I downloaded the backup tar and extracted it locally. The only reference to anything containing the word "Junk" are the .Junk folders inside the Imap Maildir folders, but those should be there. Besides, that "Junk" folder is spelled with a capital "J". I do not think that's related to the problem.

I literally have no idea where this could be coming from....
 
Phew that's a hard one.
Well, during backup the temp files are created and visible, but you can have a hard time being just in time to see it. Maybe there is a better way, but I don't know.
Very odd indeed. We don't have any backup issues after the upgrade, as don't you with the other accounts.
So it still seems something in the admin account imho, but what...

Does it happen on every backup, so if you repeat the backup, will it happen again?
Which means, is it possible for you to do a reboot so odd temp files will be gone and then try the backup of admin again, will the same thing happen again after the reboot and then backup?
Maybe install maldetect and then have check.

Maybe somebody else has another idea where to look.
 
Yep, the problem is repeatable. It happens every time I run the backup.
Correct, I have no problems with the other accounts on that server. Nor with the other servers that I manage.
I have not yet tried rebooting the server, but I'll try that next (need to find a quiet hour at night to do that).

> Well, during backup the temp files are created and visible, but you can have a hard time being just in time to see it.

I actually tried that, several times, but it's just too fast. And I know of no way to "pause" the process, so I could have a good look.


Yeah, maybe someone else can think of something I can check? I hope so. It's scary to be without backups.
 
Update:

junk.jpg

It turns out that a file with the name "c:\temp\junk.txt" does actually exist. But I stumbled upon that file just by accident, 'cause it didn't show up when I searched for it using find or grep.

Now, apart from the fact that that file should not be there, I do consider this a bug in the DirectAdmin backup software.
A backup should not fail, just because a file with that name exists, right?
 
Last edited:
I get this error message too on CentOS7 and DirectAdmin v1.650
Only user admin get error, All other users can do backup complete

An error occurred during the backup
Error Compressing the backup file /backup/sunday-admin/admin/backup/home.tar.zst : /bin/tar: .pki: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors

Use stable v1.649 No error

Thank you
 
Last edited:
I think that maybe something changed in DA v1.650 with the handling of filenames? That could explain both yours and my situation.
 
maiijarb said:
I get this error message too on CentOS7 and DirectAdmin v1.650
Only user admin get error, All other users can do backup complete

An error occurred during the backup
Error Compressing the backup file /backup/sunday-admin/admin/backup/home.tar.zst : /bin/tar: .pki: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors
Click to expand...

I get that error too on CentOS7 and DirectAdmin v1.650 :

Error Compressing the backup file /home/myserver/user_backups/2023-08-10/axxxxxcom/backup/home.tar.gz : /bin/tar: .pki: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors
Click to expand...

It seems to be a permission issue, I noticed that not all the .pki folders produce the issue, only the ones that have root as owner, in fact the most of the .pki folders have the permission of the users and no error.

May we safely put the users as owner of those folders?
 
jonium said:
May we safely put the users as owner of those folders?
Click to expand...
I wouldn't do that.

I also see this:
Code: 
Error Compressing the backup file /home/myserver/user_backups/
Normally, when using admin backup/transfer the backups are created in /home/admin/admin_backups not in /home/myserver/user_backups.

Did you change the admin backup path in the admin backup/transfer section? If yes, why? Maybe it works when you put it back to the default.

Also, if I'm not mistaken, some backup things were fixed. Maybe it's best to switch to the "current" channel and upgrade to Directadmin 1.652.
 
You must log in or register to reply here.
Back
Top