locked
WSS 3.0 Backup Fail SQL Service Account RRS feed

  • Question

  • Running WSS 3.0 on Server2008 R2 trying to execute backup from Central Administration returns error:

    Directory \\<server name>\Server Resources LUC\sharepointbackup\04_01_11 does not exist or the SQL Server service account and the LUC\Administrator service account do not have permission to read or write to the backup folder. Specify a different directory.

    This is to external D:\ SeaGate brand drive. Have also tried various naming conventions.

    Previous backup worked fine using D:\<folder name>.  The Admin user has full control.  Unsure about the SQL Server service account.  How do I troubleshoot this aspect of the problem? Or is something else going on?

    Tuesday, April 5, 2011 6:37 PM

Answers

  • Ok, just to make sure that you've checked all of this, I'm going to walk through the specific things you need to have configured on your backup storage location when using the Central Admin site to backup SharePoint:

    • You must reference your storage location with a UNC (Universal Naming Convention) path, unless you're running SharePoint and SQL Server on the same box. If you're running them on the same server, you can use a drive letter (such as D:\) to reference the storage location. If not, you have to set up the target folder as a file share and reference its UNC path (\\<server name>\<share name>) as the storage location. It looks like you're familiar with these two items based on your info, but I just wanted to mention them to be certain. Generally the UNC path is the way to go, since that will always work (as opposed to the limitations on the drive letter approach).
    • You must have enough storage space on your drive to store the backup. I'd recommend having at least 1.5 times as much storage as used by the components you're backing up. Based on the errors you're seeing I don't think this is a problem for you, but I want to mention it in case you fix your current problem and then run up against this.
    • Certain accounts need specific rights in that storage location, if they both don't have them, you'll get the error you see above. 1) The service account used as the identity of the application pool running your Central Admin site in IIS must have read and write capabilities in that directory. If it's a shared directory, it must have Read and Change rights in the share. 2) The service account used to run SQL Server services on your farm's SQL Server instance must also be able to write to the backup location.

    I suspect that the issue you're having is related to the account permissions I mention in the third bullet. Take a look at the permissions for your backup storage location and make sure that the two accounts above have the correct rights for it. I would take a look at the SQL Server instance, see what account is running the instance's services on its host, then try granting it read/write permissions for your storage location and re-running your backup.

    John


    MCITP and MCTS: SharePoint, Virtualization, Project Server 2007
    My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.
    Tuesday, April 5, 2011 7:24 PM

All replies

  • Ok, just to make sure that you've checked all of this, I'm going to walk through the specific things you need to have configured on your backup storage location when using the Central Admin site to backup SharePoint:

    • You must reference your storage location with a UNC (Universal Naming Convention) path, unless you're running SharePoint and SQL Server on the same box. If you're running them on the same server, you can use a drive letter (such as D:\) to reference the storage location. If not, you have to set up the target folder as a file share and reference its UNC path (\\<server name>\<share name>) as the storage location. It looks like you're familiar with these two items based on your info, but I just wanted to mention them to be certain. Generally the UNC path is the way to go, since that will always work (as opposed to the limitations on the drive letter approach).
    • You must have enough storage space on your drive to store the backup. I'd recommend having at least 1.5 times as much storage as used by the components you're backing up. Based on the errors you're seeing I don't think this is a problem for you, but I want to mention it in case you fix your current problem and then run up against this.
    • Certain accounts need specific rights in that storage location, if they both don't have them, you'll get the error you see above. 1) The service account used as the identity of the application pool running your Central Admin site in IIS must have read and write capabilities in that directory. If it's a shared directory, it must have Read and Change rights in the share. 2) The service account used to run SQL Server services on your farm's SQL Server instance must also be able to write to the backup location.

    I suspect that the issue you're having is related to the account permissions I mention in the third bullet. Take a look at the permissions for your backup storage location and make sure that the two accounts above have the correct rights for it. I would take a look at the SQL Server instance, see what account is running the instance's services on its host, then try granting it read/write permissions for your storage location and re-running your backup.

    John


    MCITP and MCTS: SharePoint, Virtualization, Project Server 2007
    My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.
    Tuesday, April 5, 2011 7:24 PM
  • Your third point was the solution.  I was also convinced it was a permission error because this is my biggest weakness (I know what I want but the radio button choices and I don't think the same way).  So sometimes it does security the way I want and sometimes not.  So somewhere along the way I applied permissions to be inherited and wiped out that service from the approved users.  I just added the network service as an approved user with permission to modify and it advanced to queue the backup.  I checked the progress and it is finished successful. 

    As to your other points, I have an external drive and they are all on the same server.  I have only used 1GB for backup on a 700GB drive.  And to your first point, oddly enough I switched back to a letter designated drive and it worked with D:\ but I will keep trying the UNC path until I get it right.  My real goal is to update WSS but I needed this backup first.  So now, onto the real challenge!

    Many Thanks!

    Wednesday, April 6, 2011 7:59 PM