Cpanel file permissions change automatically after system backup - backup

I've configured auto legacy backup.
Every time it does a system backup, all the 777 permissions will change to something like 750 and it causes 500 server error.
Can anyone tell me how to stop this from happening. It resets the permissions every time I do a backup.

Are you getting this issues for your all account ?
I think it's not due to backup. Might be there is other cron which is changing the account files permission from 777 to 755.
You can test this by disabling backup cron for one day and check account's file permission.

Related

cPanel / WHM restore from backup tar archive (from another cPanel server)

I am quite new to server migrations, but fairly familiar with cPanel though. My current task is to migrate an entire website from a server with cPanel to another one.
What I did so far:
Use the Backup Wizard on the old server to create a full backup archive, and FTP it to the new server.
The full archive (about 6 GB because there are a lot of images) is now in my new server's public_html directory.
Now, what I need is a way to make the server take this tar archive, which is a full backup, and restore from it.
What I tried:
I tried simply extracting the archive, but it is taking forever to finish (again the archive is 6 GB), and for some reason my browser tab has to stay open until the end of the process, otherwise the extracting halts.
Also, as I have WHM access, I tried the "Restore a Full Backup/cpmove File" option, but for some reason, under the "Username for the account that you wish to restore:" textbox, WHM does not find my cPanel username.
If anyone can either tell me what I am doing wrong, or propose another option, I would really appreciate it.
P.S.: I only have WHM access to the new server, not the old one.
Edit: I got the WHM method working now. My mistake was that my tar archive was not stored in the /home directory, but in the home directory of the cPanel user (which is /home/username)!
Move your cpanel full backup file to /home directory and if you root have access of the server use below command as /scripts/restorepkg (cpanel username )
OR
Login to WHM with root user and go through the steps mentioned on below URL.
http://documentation.cpanel.net:8090/display/68Docs/Restore+a+Full+Backup+cpmove+File

Backups marked incomplete, but seem to be full backups, while using vultr VPS with WHM Cpanel destination Amazon S3. How do I resolve this?

I'm backing up 35 or so accounts to Amazon S3. The connection is good, all of the backup files are being written, but afterwards in the backup folder I have a tiny file named 'backup incomplete' and you open it, it shows the date. The WHM/Cpanel side obviously is marking this incomplete, but I'm not sure why as the file sizes seem to be identical to the actual on-server data. I've double checked that there are no disk space issues both on the server and on the destination S3 bucket. I've verified that the backup configuration is correct, and validated the connection to the S3 bucket. I am using vultr VPS for hosting, if that matters. I do have VPS snapshots taking place but they happen about 5 hours after the S3 backup starts. I have 5 other vultr VPS servers setup with this same configuration with no issues. Any ideas on where to look to find why this is happening and resolve it?
OK! So I found my issue. Exporting of a mySQL database was failing during the backup. I found this by reviewing the cpanel log files found in /usr/local/cpanel/logs/cpbackup
For more information about cpanel logs visit:
https://documentation.cpanel.net/display/CKB/The+cPanel+Log+Files
Any empty database in a user account will cause this. In the log it looks like:
[2022-01-11 07:47:45 -0500] Determining mysql dbs...The system failed to fetch the status of the database “foo_bar” because of an error: (XID bazqux) The system received an error from the “MySQL” database “mysql”: ER_BAD_DB_ERROR (Unknown database 'foo_bar')
...
[2022-01-11 07:47:45 -0500] mysqldump: Got error: 1049: "Unknown database 'foo_bar'" when selecting the database
Trawling through a log file is tedious, but some other keywords besides "error" can be found here: https://support.cpanel.net/hc/en-us/articles/1500001997102-Backups-PartialFailure-backup-incomplete-in-our-backup-directory-and-the-old-backup-won-t-delete-prune

cPanel - No permission to download backup

Thanks in advance for any help, you guys are awesome!
A previous web developer made a backup of the site in question to the server months ago, and the permissions for this backup are 600. I can't change the permissions or download the file, although I can still move it between folders.
I've read having low disk space is sometimes the problem, but in this case there are 2 GB left, so that should be fine.
There is an other way to download backup from server to local machine, if you are able to move backup file in folders then move it to your website's home directory like '/home/user/public_html/backup.zip' and then browse it in browser and download the backup file.
http://yourdomain.com/backup.zip
It will provide you download option.

EXECUTE master.dbo.xp_delete_file folder permission issue

I'm trying to run a Maintenance Cleanup Task to remove .bak files older than 2 days (simple enough).
Been trying all variety of .bak, BAK, .*., and editing the path, but the files are still not getting removed even though I receive a "job succeeded" log message.
I'm at the point where I believe it's a folder permission issue.
How do I make sure my SA has the proper permissions to remove files from a folder?
T-SQL:
EXECUTE master.dbo.xp_delete_file 0,N'D:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Backup\',N'BAK',N'2012-06-21T11:35:59',1
Thanks.
I always have domain account with some (in your case sa) privilages on sql server. Then you add domain login to folder.

Locked SQL Server Data Files

I have an SQL Server database where I have the data and log files stored on an external USB drive. I switch the external drive between my main development machine in my office and my laptop when not in my office. I am trying to use sp_detach_db and sp_attach_db when moving between desktop and laptop machines. I find that this works OK on the desktop - I can detach and reattach the database there no problems. But on the laptop I cannot reattach the database (the database was actually originally created on the laptop and the first detach happened there). When I try to reattach on the laptop I get the following error:
Unable to open the physical file "p:\SQLData\AppManager.mdf". Operating system error 5: "5(error not found)"
I find a lot of references to this error all stating that it is a permissions issue. So I went down this path and made sure that the SQL Server service account has appropriate permissions. I have also created a new database on this same path and been able to succesfully detach and reattach it. So I am confident permissions is not the issue.
Further investigation reveals that I cannot rename, copy or move the data files as Windows thinks they are locked - even when the SQL Server service is stopped. Process Explorer does not show up any process locking the files.
How can I find out what is locking the files and unlock them.
I have verified that the databases do not show up in SSMS - so SQL Server does not still think they exist.
Update 18/09/2008
I have tried all of the suggested answers to date with no success. However trying these suggestions has helped to clarify the situation. I can verify the following:
I can successfully detach and reattach the database only when the external drive is attached to the server that a copy of the database is restored to - effectively the server where the database is "created" - lets call this the "Source Server".
I can move, copy or rename the data and log files, after detaching the database, while the external drive is still attached to the Source Server.
As soon as I move the external drive to another machine the data and log files are "locked", although the 2 tools that I have tried - Process Explorer and Unlocker, both find no locking handles attached to the files.
NB. After detaching the database I tried both stopping the SQL Server service and shutting down the Source Server prior to moving the external drive - still with no success.
So at this stage all that I can do to move data between desktop and laptop is to make a backup of the data onto the external drive, move the external drive, restore the data from the backup. Works OK but takes a bit more time as the database is a reasonable size (1gb). Anyway this is the only choice I have at this stage even though I was trying to avoid having to go down this path.
Crazy as it sounds, did you try manually granting yourself perms on the files via right-click / properties / security? I think SQL Server 2005 will set permissions on a detached file exclusively to the principal that did the detach (maybe your account, maybe the account under which the SQL Server service runs) and no-one else can manipulate the file. To get around this I have had to manually grant myself file permissions on MDF and LDF files before moving or deleting them. See also blog post at onupdatecascade.com
Can you copy the files? I'd be curious to know if you can copy the files to your laptop and then attach them there. I would guess it is some kind of permissions error also, but it sounds like you've done the work to fix this.
Are there any attributes on the file?
Update: If you can't copy the files then something must be locking them. I would check out Unlocker which I haven't tried but sounds like a good starting point. You might also try taking ownership of the files under the file permissions.
When you are in Enterprise Manager or SSMS, can you see the name of the database that you are talking about? There might be a leftover database in a funky state. I'd make sure that you have a backup or a copy of the mdf somewhere safe. If this is the case, maybe try dropping the database and then re-attaching it.
I would try backing up the database on the desktop, and then see if it will restore successfully on the laptop. Doesn't explain your issue but at least you can move forward.
Run sqlservr.exe in debug mode with the /c switch and see what happens starting up. Any locking or permissions issue can be put to bed by making a copy of the file and transfering the copy to the origional.
Also check the associated log file (.ldf) .. If that file is missing or unavaliable you will not be able to mount the database to any sane/consistant state without resorting to emergency bypass mode.
I've had a similar issue. Nothing seemed to resolve it - even tried to reboot the machine completely, restarting SQL services etc. ProcMon and ProcessExplorer were showing nothing so I figured - the "lock" is done by OS.
I resolved it by DELETING the file and restoring it back from the drive mounted under another drive letter.
PS. My database file was not on a USB drive, but on a TrueCrypt-drive (in some you can say it's a "removable drive" as well)
Within SQL Server Configuration Manager, look in SQL Server Services. For all your SQL Server instances, look at which account is selected in the Log On Tab - Log On As:. I've found for instance, changing it to the Local System account resolves the issue you've had. It was the only thing that actually worked for me - and certainly, no shortage of people have had the same problem.
It's a security issue on -file level security - you have detached db with different credential and attaching it with other credential - just browse the article http://www.sqlservermanagementstudio.net/2013/12/troubleshooting-with-attaching-and.html
And try copy pasting it to different location.
I solved similar issue by granting system administrator to all permissions:
right click > properties
security tab
in group or usernames click edit.
click add > advanced
click find now to list all available permissions.
choose administrator and add it to list.
grant it to has full permission.
I had the same issue. Someone had detached the files and left, and we were unable to move it to another drive. But after taking ownership of the file (security-->advanced-->take ownership to your login id), and then adding your login id to the security tab and giving access on the file, was able to move.