L'accès est refusé lors de la connexion d'une base de données
J'utilise SQL Server 2008 Developer Edition. J'essayais de joindre la base de données AdventureWorks2008.
Lorsque j'ai essayé de joindre, j'ai reçu une erreur "l'accès est refusé". Selon le journal des événements, il provenait du système d'exploitation:
Échec de l'ouverture: impossible d'ouvrir le fichier D:\ProjectData\AdventureWorks\AdventureWorksLT2008_Data.mdf pour le numéro de fichier 0. Erreur du système d'exploitation: 5 (accès refusé).
Je pensais que "problème NTFS", mais le système (et moi) ont modifier l'accès aux deux fichiers.
J'ai constaté que je pouvais attacher correctement la base de données si je me connectais en tant que sa, mais mon compte d'utilisateur ne fonctionnait pas.
Je suis membre du groupe des administrateurs locaux sur ma machine et je joue le rôle administrateur système dans l'instance SQL Server.
Une idée de la raison pour laquelle je devais être connecté en tant que sa?
Merci pour tous les commentaires. Certains d'entre vous ont contribué à m'amener à la réponse. Voici ce que j'ai trouvé:
C’était un problème d’autorisation NTFS et non un problème SQL. En outre, cela ressemble à un bug (et il est répétable).
Le problème: Le compte que j'utilisais disposait d'autorisations NTFS de contrôle total sur les fichiers mdf et ldf. Cependant, il disposait de ces autorisations par le biais de l'appartenance à un groupe (le groupe Administrateurs locaux avait des autorisations et mon compte est membre des administrateurs locaux). (J'ai vérifié les permissions)
Si j'essaie de faire l'attachement, connectez-vous à SQL Server en tant que moi (où je suis dans le groupe des administrateurs), le problème avec NTFS échoue.
Cependant, si j'accorde les mêmes autorisations de fichier que le groupe d'administrateurs local a directement à mon compte de domaine, je peux m'attacher sans aucun problème.
(oh, et oui, j'ai vérifié les groupes locaux sur cette machine et j'ai vérifié que mon compte de domaine est bien un membre du groupe d'administrateurs locaux).
Ainsi, il semble que l'erreur se produise car un code (dans SQL Server ou Management Studio) recherche les autorisations détenues par le compte d'utilisateur, mais ne va pas jusqu'à vérifier les autorisations de groupe héritées par le compte d'utilisateur.
Cela me semble bizarre, mais comme je peux le reproduire encore et encore, j’en ai conclu que c’était la solution.
Mise à jour: J'ai signalé ceci comme un bogue: https://connect.Microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-health-
Exécutez SQL Server Management Studio en tant qu'administrateur. (clic droit-> exécuter en tant qu'administrateur) qui a pris en charge toute l'étrangeté dans mon cas.
SQL SRV EXPRESS 2008 R2. Windows 7
J'aimerais ajouter des informations supplémentaires aux réponses postées.
Faites attention lorsque vous détachez la base de données parce que l'utilisateur windows vous êtes connecté en tant que devient le seul utilisateur autorisé à accéder au fichier .mdf! Les autorisations d'origine du fichier .mdf, qui comprenait l'utilisateur SQLServerMSSQLUser$<computer_name>$<instance_name> et le compte Administrateurs, sont écrasées par l'utilisateur Windows sous lequel vous êtes connecté (et non par l'utilisateur du serveur SQL). Boom, toutes les autorisations ont disparu comme ça. Faites comme les autres, cliquez avec le bouton droit de la souris sur votre fichier .mdf et vérifiez les autorisations.
J'ai rencontré ce problème car j'ai utilisé SSMS pour me connecter à la base de données (peu importe le compte de serveur SQL) et détaché la base de données. Après cela, mon utilisateur Windows était le seul à avoir des autorisations sur le fichier .mdf. Donc, plus tard, lorsque j'ai essayé de joindre la base de données en utilisant le compte sa, il a renvoyé l'erreur "accès refusé".
Pour conserver les autorisations d'origine, vous devez mettre la base de données hors ligne, puis vous en détacher, puis l'attacher dans cet ordre, de la manière suivante:
USE [master]
GO
-- kick all users out of the db
ALTER DATABASE mydb
SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
-- Take the Database Offline
ALTER DATABASE mydb SET OFFLINE WITH
ROLLBACK IMMEDIATE
GO
-- detach the db
EXEC master.dbo.sp_detach_db @dbname = N'mydb'
GO
Ajoutez une autorisation au dossier dans lequel se trouve votre fichier .mdf.
Cochez ce nom: NT Service\MSSQLSERVER
Et changez la Location en votre nom de serveur.
Ce problème est causé par UAC (User Account Control), n'est-ce pas? Bien que votre compte d'utilisateur soit membre du groupe Administrateurs, le contrôle de compte d'utilisateur de Windows 7 ne vous autorise pas à effectuer des tâches d'administrateur, sauf si vous exécutez des programmes "en tant qu'administrateur". Ce n'est pas un vrai bogue dans SQL Server, Management Studio ou autre. (Bien qu'il puisse éventuellement connaître le problème et vous demander des autorisations élevées au lieu de simplement vous plaindre "erreur 5".)
Exécutez SQL Server Management Studio en tant qu'administrateur. (clic droit-> exécuter en tant qu'administrateur) a travaillé pour moi avec Windows 7 - SQL Server 2008 R2
Une base de données SQL2005 peut être attachée de cette manière dans Windows 7:
start menu >
all program >
Microsoft sql server 2005 >
sql server management studio >
right click >
run as administrator >
click ok
Et puis la base de données attachée terminée avec succès.
Lorsque vous vous connectez en tant que sa (ou tout autre compte SQL Server), vous utilisez le compte de service SQL Server. Lorsque vous êtes connecté en tant que vous, vous disposez des autorisations de votre compte. Pour une raison quelconque, vous ne disposez pas de l'accès au fichier approprié, mais du compte de service.
Avec moi - Sous Windows 8 - Droit cliquez sur SQL Server Manager Studio -> Exécuter avec admin -> attacher pas de problèmes
il peut être corrigé facilement mais radicalement, allez simplement dans le dossier où vous avez stocké fichier mdf . sélectionnez fichier-> clic droit -> cliquez sur propriétés et donnez toutes les autorisations au fichier pour l'utilisateur connecté dans la sécurité .
J'ai trouvé cette solution: Faites un clic droit sur le dossier dans lequel vous stockez votre fichier .mdf -> cliquez sur Propriétés -> choisissez l'onglet Sécurité, cliquez sur Modifier ... et donnez-lui le contrôle total .
L'utilisateur sa utilise les comptes NTFS SQLServerMSSQLUser$<computer_name>$<instance_name> et SQLServerSQLAgentUser$<computer_name>$<instance_name> pour accéder aux fichiers de base de données. Vous voudrez peut-être essayer d'ajouter des autorisations pour l'un ou les deux utilisateurs.
Je ne sais pas si résout votre problème puisque vous dites que vous n'avez aucun problème avec l'utilisateur sa, mais j'espère que cela aidera.
À chaque fois que je rencontrais ce problème, je tentais de joindre une base de données se trouvant dans un répertoire différent du répertoire de base de données par défaut configuré dans SQL Server.
Je recommanderais vivement de ne pas déplacer les fichiers de données dans le répertoire que SQL Server s'attend à trouver, au lieu d'autoriser des autorisations sur différents répertoires et comptes.
Je voulais juste ajouter cette information aussi.
http://www.mssqltips.com/sqlservertip/2528/database-attach-failure-in-sql-server-2008-r2/
Solution
Vous obtenez cette erreur parce que deux opérations de connexion différentes ont effectué les opérations de détachement et d'attachement. Ainsi, les fichiers, une fois détachés, appartenaient au premier login, mais l'attachement a échoué car le login utilisé n'était pas le propriétaire des fichiers mdf et ldf.
Lorsque nous séparons des fichiers de base de données, le propriétaire devient la personne qui a exécuté la commande detach. Par conséquent, pour résoudre le problème, nous devons modifier ou ajouter l'autre identifiant de connexion en tant que propriétaire des fichiers mdf et ldf.
Cliquez avec le bouton droit sur le fichier "nomfichier.mdf" et sélectionnez Propriétés pour vérifier les autorisations du fichier mdf. Ici, nous pouvons voir qu'un seul compte a l'autorisation sur le fichier "nomfichier.mdf", car il s'agissait du compte utilisé pour détacher la base de données.
Pour résoudre ce problème, cliquez sur le bouton Ajouter ... pour ajouter l'autre identifiant ou tout autre identifiant requis et attribuez un contrôle total à l'identifiant. Vous devriez également faire cela pour le fichier "ldf". Une fois cette tâche terminée, cliquez sur le bouton OK. (Remarque: pour les autres versions de système d'exploitation, vous pouvez avoir une option Modifier, cliquez dessus puis vous verrez l'option Ajouter ...).
Pour ce que cela vaut à quiconque ayant la variation particulière de ce problème que j'ai eu:
- SQL Express 2008
- Visual Studio 2010 Premium
Dans le menu contextuel du dossier App_data, j'avais créé une base de données SQL Express à des fins de débogage. La chaîne de connexion (utilisée par NHibernate) était la suivante:
Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;
Cela m'a donné la même erreur "Accès refusé" sur le fichier de base de données. J'ai essayé de donner aux différents utilisateurs un contrôle total sur le dossier et les fichiers, même à un moment donné pour "Tout le monde". Rien n'a aidé, alors j'ai supprimé les autorisations ajoutées à nouveau.
Ce qui a finalement résolu le problème a été d'ouvrir l'Explorateur de serveurs dans Visual Studio, puis de se connecter au MDF et de le détacher à nouveau. Après cela, mon application Web pouvait très bien accéder à la base de données.
PS. Les crédits vont à cet article de blog J'ai trouvé en cherchant ce problème particulier dans Google, ce qui a déclenché l'idée de joindre/détacher la base de données pour résoudre le problème.
USE [master]
GO
CREATE DATABASE [DataBasename] ON
( FILENAME = N'C:\data\DataBasename.mdf' )
FOR ATTACH
GO
changer à FOR ATTACH -> FOR ATTACH_FORCE_REBUILD_LOG
USE [master]
GO
CREATE DATABASE [DataBasename] ON
( FILENAME = N'C:\data\DataBasename.mdf' )
FOR ATTACH_FORCE_REBUILD_LOG
GO
J'ai eu cette erreur en tant que sa . Dans mon cas, la sécurité de la base de données importait peu… .. J'ai ajouté le contrôle total de chacun aux fichiers mdf et ldf,.
J'ai eu le même problème en attachant une base de données. Ce n'était pas un problème de SQL, c'était un problème de compte. Allez dans le panneau de contrôle/Paramètres de contrôle de compte d'utilisateur/Définissez sur "ne jamais notifier" Enfin, redémarrez l'ordinateur et cela a fonctionné pour moi.
J'ai joint le fichier mdf en faisant un clic droit sur la base de données et en supprimant le fichier journal AdventureWorks2012_Data_log.ldf dans l'assistant. Le fichier mdf a été placé à l'emplacement suivant
C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA
La méthode ci-dessus m'a aidé à résoudre le problème.
Je lisais cette page et ils ont une phrase intéressante dedans:
Attention: Soyez très sélectif lorsque vous ajoutez les utilisateurs à ces rôles. Par exemple, sysadmin mappe sur dbo dans chaque base de données et est l’équivalent de se connecter en utilisant le compte sa.
Bien sûr, ils ont aussi ceci:
Autorisations accordées aux utilisateurs et les rôles et sont spécifiques à la base de données . Toutes les autorisations sont cumulatives avec l'exception d'un DENY. Un refusé autorisation au niveau utilisateur ou au niveau du rôle remplace le même autorisation accordée via un autre rôle les adhésions à l’exception du sysadmin rôle de serveur fixe. (A Sysadmin conserve toutes les autorisations, même Si un rôle dont il est membre possède une autorisation DENY.)
Donc, si vous êtes un administrateur de domaine et dans le groupe sysadmin 'de SQL, le monde devrait être votre crustacé.
Bien sûr, selon Microsoft, vous devriez jeter un coup d’œil sur ces deux pages:
Lien vers les conditions préalables de la base de données
Lien vers l'installation de bases de données
Vous êtes méchant et essayez de les attacher manuellement :) Sérieusement, avez-vous toutes les conditions préalables pour la base de données AdventureWorks2008?
Je soupçonne qu’il s’agit là d’une autre affaire Microsoft Oddity/Edge, mais je peux me tromper.
Cela ressemble aux autorisations NTFS. Cela signifie généralement que votre compte de service SQL Server dispose d'un accès en lecture seule au fichier (notez que SQL Server utilise le même compte de service pour accéder aux fichiers de base de données, quel que soit le mode de connexion utilisé). Êtes-vous sûr de ne pas avoir modifié les autorisations de dossier entre vous connecter en tant que vous et vous connecter en tant que sa? Si vous vous détachez et essayez à nouveau, le problème persiste-t-il?
J'ai déplacé une base de données mdf du dossier Data par défaut vers mon dossier asp.net app_data et j'ai rencontré ce problème en essayant de remettre la base de données en ligne.
J'ai comparé les paramètres de sécurité des autres bases de données de fichiers de l'emplacement d'origine aux fichiers déplacés et j'ai constaté que MSSQL $ SQLEXPRESS ne disposait pas des autorisations nécessaires pour les fichiers situés à son nouvel emplacement. J'ai ajouté le contrôle total pour "NT SERVICE\MSSQL $ SQLEXPRESS" (doit inclure ce service NT) et le tout s'est bien attaché.
Il semble que le dossier de données d'origine possède ces autorisations et que les fichiers en héritent. Déplacez les fichiers et les ruptures d'héritage bien sûr.
J'ai vérifié le fichier mdf d'un autre projet que j'ai créé directement dans son dossier app_data. il ne dispose pas des autorisations MSSQL $ SQLEXPRESS. Hmmm. Je me demande pourquoi SQL Express aime l’un mais pas l’autre?
Pour ceux qui ne pouvaient pas résoudre le problème avec les autres solutions ici, le correctif suivant a fonctionné pour moi:
Allez dans le dossier "DATA" de votre installation SQL Server, cliquez avec le bouton droit de la souris, sur les propriétés, sur l'onglet Sécurité, puis ajoutez des autorisations de contrôle total pour l'utilisateur "NETWORK SERVICE".
http://decoding.wordpress.com/2008/08/25/sql-server-2005-expess-how-to-fix-error-3417/
(Le lien ci-dessus concerne SQL 2005, mais cela a corrigé l'installation de SQL 2008 R2 pour moi).
Quelques informations supplémentaires: Ce problème s’est manifesté après le remplacement d’un disque dur secondaire (sur lequel l’installation de SQL était allumée). J'ai copié tous les fichiers et restauré la lettre de lecteur d'origine sur le nouveau disque dur. Cependant, les autorisations de sécurité n'ont pas été copiées. Je pense que la prochaine fois, j'utiliserai une meilleure méthode de copie des données.
Il s’agit en fait d’autorisations NTFS et d’un bogue étrange dans SQL Server. Je ne suis pas sûr que le rapport de bogue ci-dessus soit exact ou puisse faire référence à un bogue supplémentaire.
Pour résoudre ce problème sous Windows 7, j'ai exécuté SQL Server Management Studio normalement (pas en tant qu'administrateur). J'ai ensuite tenté de joindre le fichier MDF. Au cours du processus, j'ai utilisé l'interface utilisateur plutôt que de coller dans le chemin. J'ai remarqué que le chemin était coupé de moi. En effet, l'utilisateur MS SQL Server (SQLServerMSSQLUser $ machinename $ SQLEXPRESS) que le logiciel ajoute pour vous n'a pas les autorisations nécessaires pour accéder au dossier (dans ce cas, un dossier situé dans mes propres dossiers utilisateur).
Le collage du chemin et la procédure résultent en l'erreur ci-dessus. Alors, j’ai donné à l’utilisateur MS SQL Server les autorisations de lecture en commençant par le premier répertoire auquel il a été refusé (mon dossier d’utilisateur). J'ai ensuite immédiatement annulé l'opération de propagation, car cela peut prendre une éternité, puis j'ai à nouveau appliqué des autorisations de lecture au prochain sous-dossier nécessaire, et je l'ai laissé se propager entièrement.
Enfin, j'ai donné à l'utilisateur MS SQL Server les autorisations de modification des fichiers .mdf et .ldf pour la base de données.
Je peux maintenant joindre aux fichiers de base de données.
J'ai eu le même problème lorsque j'ai réattaché la base de données après l'avoir détachée et après avoir déplacé les fichiers ldf et mdf du lecteur C au lecteur F.
Afin de résoudre ce problème, je devais ajouter le principal OWNER RIGHTS aux deux fichiers et lui donner le plein contrôle dans l'onglet Sécurité de la boîte de dialogue Propriétés.
J'ai résolu le problème en déplaçant simplement le fichier .mdf que vous voulez joindre au dossier public. Dans mon cas, je l'ai déplacé dans le dossier utilisateurs/public. Ensuite, je l'attache à partir de là sans aucun problème. J'espère que cela t'aides.
Dans mon cas, le problème résolu était le suivant:
USE [master]
GO
CREATE DATABASE [AdventureWorks2008R2] ON
( FILENAME = 'C:\Program Files\Microsfot SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\AdventureWors2008R2_Data.mdf')
FOR ATTACH_REBUILD_LOG
Copiez la base de données dans un autre dossier et attachez ou connectez-vous à SQLServer avec "Authentification Windows"
J'ai eu du mal avec SSMS (2016) à attacher la base de données AdventureWorks2012. Mais eu le succès avec ce code, tiré de un article CodeProject par Mohammad Elsheimy :
CREATE DATABASE AdventureWorks2012
ON PRIMARY (FILENAME='D:\Dev\SQL Server\AdventureWorks2012.mdf')
FOR ATTACH;
Si vous exécutez SQL Server 2012, vous pouvez obtenir cette erreur en essayant de joindre une version plus ancienne d'un fichier mdf. ex un fichier mdf de SQL Server 2008.