web-dev-qa-db-fra.com

Erreur de restauration SQL Server - Accès refusé

J'ai créé une base de données sur mon ordinateur local, puis une sauvegarde appelée tables.bak de la table DataLabTables

J'ai déplacé cette sauvegarde sur une machine distante sans cette table et j'ai essayé de faire une restauration mais j'ai le message d'erreur suivant:

System.Data.SqlClient.SqlError: le système d'exploitation a renvoyé le fichier erreur '5 (Accès refusé.)' lors de la tentative 'RestoreContainer :: ValidateTargetForCreation' sur 'c:\Program Fichiers\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf '.

Comment puis-je régler mes droits, si tel est le problème?

139
cdub

Je viens d'avoir ce problème avec SQL Server 2012.

En fin de compte, il me suffisait de cocher la case "Déplacer tous les fichiers dans un dossier" dans la section "Fichiers":

 enter image description here

(Cliquez pour voir l'image en taille réelle)

Bien entendu, cela suppose que la version correcte de SQL Server est installée.

420
Exile

Le message d'erreur indique qu'il y a une erreur lors de la validation du cible (c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) de votre opération de restauration.

Cela ressemble à:

a) ce fichier existe déjà (car vous l'avez déjà restauré précédemment) et est utilisé par SQL Server

ou

b) ce répertoire n'existe pas du tout

Dans votre question, vous avez mentionné que vous avez créé une sauvegarde pour cette table. Ce n'est pas ainsi que fonctionnent les sauvegardes SQL Server. Ces sauvegardes sont toujours la base de données entière (ou au moins un ou plusieurs groupes de fichiers de cette base de données).

Mon intuition est la suivante: vous avez déjà restauré cette base de données et maintenant, lors d'une seconde restauration, vous n'avez pas coché la case "Remplacer la base de données existante" dans votre assistant de restauration. Le fichier existant ne peut donc pas être remplacé et la restauration échoue.

L'utilisateur qui exécute la restauration sur votre serveur distant n'a évidemment pas accès à ce répertoire sur le serveur distant.

C:\program files\.... est un répertoire protégé - les utilisateurs normaux (non-administrateurs) n'ont pas accès à ce répertoire (et à ses sous-répertoires) .

La solution la plus simple: essayez de placer votre fichier BAK ailleurs (par exemple, C:\temp) et de le restaurer à partir de là

30
marc_s

J'avais le même problème. Il s'est avéré que mes services SQL Server et SQL Server Agentlogon as étaient exécutés sous le compte Network Services sans accès en écriture pour effectuer la restauration de la sauvegarde.

J'ai changé ces deux services pour ouvrir une session en tant que Local System Account et cela a résolu le problème.

23
Flea

Récemment, j'ai rencontré ce problème avec SQL 2008 R2 et la solution ci-dessous a fonctionné pour moi:

1) Créez une nouvelle base de données portant le même nom que celui que vous essayez de restaurer 2) Lors de la restauration, utilisez le même nom que celui utilisé ci-dessus et dans les options, cliquez sur l'option de remplacement. 

Vous pouvez essayer ce qui précède si les autres solutions ne fonctionnent pas. 

9
Devin

Le créateur de la sauvegarde avait installé la version 10 de MSSql. Ainsi, lors de la sauvegarde, il stockait également le chemin de fichier d'origine (pour pouvoir le restaurer au même emplacement), mais j'avais la version 11, de sorte qu'il ne trouvait pas le répertoire de destination.

J'ai donc changé le répertoire du fichier de sortie en C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\et il a été capable de restaurer la base de données avec succès.

La source

6
Philluminati

J'avais un problème similaire. J'ai essayé de restaurer un fichier .bak 2005 et j'ai reçu exactement la même erreur. J'ai également choisi l'option de réécriture en vain.

ma solution a été d'accorder à l'utilisateur SQL l'accès au répertoire en question, en accédant au dossier et en modifiant les droits d'accès via l'écran de propriétés. 

6
martijn

perdu quelques heures à ce problème aussi. ça va bien: 

"accès refusé" dans mon cas voulait vraiment dire "accès refusé". Le compte d'utilisateur de mssqlstudio sur mon périphérique Windows N'A PAS le plein contrôle du dossier spécifié dans le message d'erreur. Je lui ai donné le plein contrôle. l'accès n'était plus refusé et la restauration a réussi. 

pourquoi le dossier était-il verrouillé pour le studio? qui sait ? J'ai eu assez de questions à traiter telles quelles sans essayer de répondre davantage.

2
abraham tio

J'ai eu ce problème, je me suis connecté en tant qu'administrateur et le problème a été résolu.

1
Rob Smith

Un autre scénario pourrait être l’existence de plusieurs chemins de base de données. Tout d’abord, notez le chemin où les nouvelles bases de données sont actuellement stockées. Donc, si vous créez une nouvelle base de données vide et que vous faites ensuite Tasks/Restore, assurez-vous que le chemin que la restauration tente d'utiliser est identique au répertoire dans lequel la base de données vide a été créée. erreur refusée si ce n'est pas le chemin actuel avec lequel vous travaillez. Très facile à repérer quand le chemin n'est pas légal, beaucoup plus difficile à repérer quand le chemin est légal, mais pas le chemin actuel.

0
demongolem

Essaye ça:

Dans la fenêtre de l'assistant de restauration de la base de données, allez dans l'onglet Fichiers, décochez la case "Déplacer tous les fichiers dans un dossier" puis changez la destination de la restauration de C: en un autre lecteur. Continuez ensuite avec le processus de restauration habituel. Il sera restauré avec succès.

0
Raja Sekhar

J'ai eu le même problème, mais j'ai utilisé SQL Server 2008 R2, vous devez vérifier les options et vérifier les chemins d'accès où SQL va enregistrer les fichiers .mdf et .ldf vous devez sélectionner le chemin d'installation de votre serveur SQL. J'ai résolu mon problème avec ceci, j'espère que cela vous aidera.

0
Edgar Castillo

Désolé car je ne peux pas commenter ...

J'ai eu le même problème. Dans mon cas, le problème était lié à la tentative de restauration dans un ancien dossier de serveur SQL (qui existait déjà sur le serveur). Ceci est dû à l'ancienne sauvegarde du serveur SQL (sauvegarde SQL Server 2012) restaurée sur un nouveau serveur SQL (SQL Server 2014). Le vrai problème n’est pas si différent de la réponse de @marc_s. Quoi qu'il en soit, je n'ai changé que le dossier cible pour le nouveau dossier SQL Server DATA.

0
bubi

Dans mon cas, j'ai dû revérifier le chemin de sauvegarde de la base de données à partir de laquelle je restaurais. Je l'avais précédemment restauré à partir d'un chemin différent lorsque je l'avais fait la première fois. J'ai corrigé le chemin de sauvegarde pour utiliser le chemin de sauvegarde que j'avais utilisé la première fois et cela a fonctionné!

0
SitecoreSyed

Vous avez un problème comme ça. Erreur provoquée par la compression activée sur les dossiers SQL Server.

0
Arman Hayots

Frnds ... J'ai eu le même problème lors de la restauration de la base de données et j'ai essayé toutes les solutions, mais je n'ai pas réussi à le résoudre. Ensuite, j'ai essayé de réinstaller SQL 2005 et le problème résolu. Actully la dernière fois que j’ai oublié de vérifier l’option de personnalisation lors de l’installation de SQL. Elle est livrée deux fois lors de l’installation et je l’ai vérifiée uniquement.

0
Nishant

Ce n'est peut-être pas la meilleure solution, mais j'essayais de restaurer SQL Server 2005, mais j'ai changé pour SQL Server 2008 et cela a fonctionné.

0
alansiqueira27