BackupBuddy Plugin Error - database

When backing up the whole site. This is the Error
-- Backing up with BackupBuddy v2.2.33...
15:10:14: Error #5445589. Invalid backup serial (9au6kfm0rj). Verify backup directory writer permission. Fatal error.
A fatal error has been encountered. The backup has halted. --
Solutions from the support ->
Adjust permissions to allow write & directory creation access to your uploads folder. ie: /www/wp-content/uploads/
How can i adjust the permission? Any idea please?

Do you have FTP access to your site? If you access it with an FTP program like Filezilla or SmartFTP you should be able to browse to the uploads folder and right-click to bring up the options and change the permissions.
If you don't have your FTP details or have issues accessing that then the best bet is probably to email your webhost with the above information and ask can they change the permissions for you on that folder.

Related

Deployed SSIS package will not read a file

I have an SSIS package that is supposed to read a folder and if the folder contains any text files, it will read them and store the data into a database. The package works flawlessly from the file system, however when I deployed it it fails.
The package uses a project level variable that remains consistent that acts as a folder path to see which folder to look in for files.
The SQL Server Agent gives me this error:
After looking at the execution report I see following error messages if I execute it with the service account through SQL Server Agent:
"The file name property is not valid. The file name is a device or contains invalid characters"
"The file name '(path here)' specified in the connection was not valid"
"The Flat File Connection manager failed validation"
However, if I run it myself by directly right clicking on the package in the catalog and executing, the execution report will come back as successful but it will contain a warning that says: "Read Files From File Input Folder Warning: The For Each File enumerator is empty. The For Each File enumerator did not find any files that matched the file pattern, or the specified directory was empty"
I suspect it is a permissions error, but I haven't dealt much with the permissions in Microsoft SQL Server and the service account that I am using was not created by me. I have tried changing the security of both package and project from the default "Encrypt sensitive data with user key" to "Do not save sensitive data", rebuilding and redeploying but that didn't help at all.
It is most likely a permissions error but I've been puzzled on how to go about it. Any help is much appreciated!
EDIT: After setting the "Delay Validation" on tasks in the control flow and executing the package with SQL Server Agent it now comes back with 2 less errors
For filesystem task to work the executing account need permission to the folder in question. When you execute the package via the SQL-agent the package is executed under the account running the SQL-agent account, when you right click the package and press execute the package is executed as your account.
One problem could be that the SQL-agent account doesn't have permission to the folder, and can't enumerate the content. You can verify this by changing the SQL-server account to your own account temporary and running the job again:
Open Sql Server Configuraiton Manager
Under SQL Server Services double click SQL Server Aggent
Change the account to your own account
Restart the service
If this resolvs the problem, change back to the SQL-server account and check the folder permissions on the folder you are trying to enumerate. Add the SQL-agent account or group the account is included in to have permission to read the folder. Obviously you can also just check the folder permissions to begin with, and make sure the executing account have permission to it.

Why full control permissions on a folder are not inherited by a crt or a pvk file created in the folder?

I have a network folder and two machine accounts, node1$ and node2$, both of them having full control permission on the folder.
I log in a SQL Server instance in the node1 machine and back up a SQL Server certificate on the network folder, which generates a crt and a pvk files.
Then I log in node2 machine and try to restore the certificate in another SQL Server instance. But I can't because node2$ has no permissions on the requested files .crt and .pvk.
Even more, if I check the created files, the very node$1 machine account has no explicit permissions on these files. Instead, I find an "owner rights" ACE.
So, the files don't seem to inherit the permissions that node1$ and node2$ have on the folder.
This issue doesn't occur with other kind of files.
I can solve this by manually assigning explicit permissions on the files to node2$.
But my question is: why .crt and .pvk files don't inherit the permissions as other types of file do?
The documentation explains it:
When performing a backup, the files will be ACLd to the service account of the SQL Server instance. If you need to restore the certificate to a server running under a different account, you will need to adjust the permissions on the files so that they are able to be read by the new account.
As you already figured out: inheritance is disabled because the T-SQL command BACKUP CERTIFICATE explicitly removes all permissions but for the service account.

How do I change the path to a dropbox folder

I want to move my .mdf and .ldf into my dropbox folder.
I ran this script command:
ALTER DATABASE MyDatabase1 MODIFY FILE
(
Name = matrix,
Filename = 'C:\Users\mycomputer\Dropbox\MyDatabase1.mdf'
);
But I get this error:
The path specified by 'C:\Users\mycomputer\Dropbox\MyDatabase1.mdf' is
not in a valid directory.
I'm pretty sure it's just a permissions issue where the sql service running my script doesn't have the correct permissions. But I have no clue which object to grant all permissions to my DropBox. I tried mycomputer\users but that didn't work. Can someone help please?
As far as I know, Dropbox does not make snapshots of the files it copies.
This means the files could (and most probably would) be written to during the copy and they'll arrive in inconsistent state, rendering them unusable.
I believe you would want to use Log Shipping instead. This is a feature of SQL Server which allows transaction logs to be incrementally backed up and sent to another server (possibly by means of Dropbox), where they can be restored. This would allow you to have a snapshot of the database on another server.

TFS InvokeMethod Delete Access to the path is denied

I am trying to call invokemethod to delete a file in the drop folder. However I am receiving access to the path is denied message. I am also doing copydirectories and delete directory before using invokmethod. Both copy and delete directories work with no permission issue.
I am guessing invokemethod use different user account. Any help is very much appreciated.
By default the build agent runs with the build service account of Network Service. You may want to change it to a domain account such as TFSBuild so you could assign write permissions on the paths you need your build artifacts.
Then make sure TFSBuild is running the build service and is a member of the Project Collection Build Service Accounts
You will also get access denied error, when you have the file in use.

SQL SERVER Install change Hard disk permissions?

I did an install of SQL SErver 2008 and the client wanted to have the data file at the root of the hard disk, and the log file at the root of another hard disk.
Prior to me doing install I could browse those harddisks because I am a member of the local admins. After the install I got permission denied.
To get around this, I had to grant myself the ability to take ownership of hard disks, which I went to security and set myself as the owner, and then give myself specific rights to each of the harddisks, even though there was local admins already assigned the rights to do everything.
So is there something I don't know about installing sql server data directories to the root directory that affects the permissions? There were files there before and after the install.
It seems to be done to prevent data and log files from being modified by users. Details are in the following article from MSDN:
Securing Data and Log Files

Resources