L'accès est refusé lors de la connexion d'une base de données

J'utilise l'édition développeur de SQL Server 2008. 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 de l'O / S:

Échec d'ouverture: impossible d'ouvrir le fichier D: \ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdf pour le fichier numéro 0. Erreur du système d'exploitation: 5 (l'accès est refusé.).

Je pensais "problème NTFS", mais System (et moi) avons modifié l'accès aux deux fichiers.

J'ai constaté que je pouvais joindre la base de données avec succès si je me connectais en tant que sa, mais mon compte d'utilisateur ne fonctionnera pas.

Je suis membre du groupe des administrateurs locaux sur ma machine et je suis dans le rôle d'administrateurs système dans l'instance SQL Server.

Une idée de pourquoi je devais être connecté en tant que sa?

Exécutez SQL Server Management Studio en tant qu'administrateur. (clic droit -> exécuter en tant qu'administrateur) qui a pris soin de toute la bizarrerie dans mon cas.

SQL SRV EXPRESS 2008 R2. Windows 7

Merci pour tous les commentaires. Certains d'entre vous m'ont aidé à trouver la réponse. Voici ce que j'ai trouvé:

C'était un problème d'autorisation NTFS, et non un problème SQL. De plus, cela ressemble à un bug (et c'est répétable).

Le problème: le compte que j'utilisais avait des autorisations NTFS de contrôle total sur les fichiers mdf et ldf. Cependant, il avait ces autorisations via l'appartenance à un groupe (le groupe Administrateurs locaux avait des autorisations et mon compte est membre d'administrateurs locaux). (J'ai vérifié les autorisations)

Si j'essaie de faire l'attachement, de me connecter à SQL Server en tant que moi (où je suis dans le groupe admins), cela échoue avec le problème NTFS.

Cependant, si j'accorde les mêmes autorisations de fichier que le groupe d'administrateurs local directement sur mon compte de domaine, je peux attacher sans 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 des administrateurs locaux).

Ainsi, il semble que l'erreur se produit car un certain code (dans SQL Server ou Management Studio) vérifie les autorisations détenues par le compte d'utilisateur, mais il ne va pas jusqu'à vérifier les autorisations de groupe dont le compte d'utilisateur hérite.

Cela me semble étrange, mais je peux le reproduire encore et encore, alors j'ai conclu que c'était la réponse.

Mise à jour: J'ai signalé cela comme un bogue: https://connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited

Je voudrais ajouter des informations supplémentaires aux réponses qui ont été publiées.

Soyez prudent lorsque vous détachez la base de données car l' utilisateur Windows sous lequel vous êtes connecté devient le seul utilisateur avec des autorisations sur le fichier .mdf! Les autorisations d'origine du fichier .mdf qui incluaient l'utilisateur SQLServerMSSQLUser$<computer_name>$<instance_name>et le compte Administrateurs sont écrasées par l'utilisateur Windows sous lequel vous êtes connecté (pas l'utilisateur du serveur SQL). Boom, toutes les autorisations sont parties comme ça. Alors faites comme d'autres l'ont dit et faites un clic droit 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 (quel que soit 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 jeté l'erreur «accès refusé».

Pour garder les autorisations d'origine intactes, vous devez mettre la base de données hors ligne, puis la détacher, puis l'attacher dans cet ordre comme suit:

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 l'autorisation au dossier où se trouve votre .mdffichier.

Vérifiez ce nom: NT Service\MSSQLSERVER

Et changez le nom Locationde votre 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, l'UAC dans Windows 7 ne vous permet pas d'effectuer des tâches d'administrateur à moins que vous n'exécutiez des programmes «en tant qu'administrateur». Ce n'est pas un vrai bogue dans SQL Server ou 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 se plaindre de «l'erreur 5».)

Exécutez SQL Server Management Studio en tant qu'administrateur. (clic droit-> exécuter en tant qu'administrateur) a fonctionné 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 base de données attachée terminée avec succès.

Lorsque vous vous connectez en tant que sa(ou n'importe quel compte Sql Server), vous travaillez en tant que 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 aux fichiers approprié, mais le compte de service en a.

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 un contrôle total. J'espère que cela t'aides!

L' sautilisateur utilise des comptes NTFS SQLServerMSSQLUser$<computer_name>$<instance_name>etSQLServerSQLAgentUser$<computer_name>$<instance_name> pour accéder aux fichiers de la base de données. Vous voudrez peut-être essayer d'ajouter des autorisations pour l'un de ces utilisateurs ou les deux.

Je ne sais pas si cela résout votre problème puisque vous dites que vous n'avez aucun problème avec l' sautilisateur, mais j'espère que cela aide.

Avec moi - Exécution sur la fenêtre 8 - Cliquez avec le bouton droit sur SQL Server Manager Studio -> Exécuter avec l'administrateur. -> attacher aucun problème

il peut être corrigé facilement mais radicalement, allez simplement dans le dossier où vous avez stocké le fichier mdf . sélectionnez fichier-> clic droit -> cliquez sur les propriétés et donnez les autorisations complètes au fichier pour la sécurité de l'utilisateur connecté .

Chaque fois que j'ai rencontré ce problème, c'était lors de la tentative de connexion d'une base de données qui se trouve dans un répertoire différent du répertoire de base de données par défaut configuré dans le serveur SQL.

Je recommanderais vivement qu'au lieu de détourner des autorisations sur divers répertoires et comptes, vous déplaciez simplement votre fichier de données dans le répertoire que le serveur SQL attend de le trouver.

Je voulais juste ajouter ces informations également.

http://www.mssqltips.com/sqlservertip/2528/database-attach-failure-in-sql-server-2008-r2/

Solution

Vous obtenez cette erreur car deux connexions différentes ont effectué les opérations de détachement et d'attachement. Ainsi, les fichiers, une fois détachés, appartenaient à la première connexion, mais la pièce jointe a échoué car la connexion utilisée n'était pas le propriétaire des fichiers mdf et ldf.

Lorsque nous détachons des fichiers de base de données, le propriétaire devient la personne qui a exécuté la commande detach, donc pour résoudre le problème, nous devons modifier ou ajouter l'autre connexion en tant que propriétaire des fichiers mdf et ldf.

Cliquez avec le bouton droit sur le fichier "filename.mdf" et sélectionnez les propriétés pour vérifier les permissions du fichier mdf. Ici, nous pouvons voir qu'un seul compte a la permission sur le fichier "filename.mdf" car c'était le compte qui a été utilisé pour détacher la base de données.

Pour résoudre ce problème, cliquez sur le bouton Ajouter ... pour ajouter l'autre connexion ou toute autre connexion nécessaire et donner le contrôle total de la connexion. Vous devez également le faire pour le fichier "ldf". Une fois cette tâche terminée, cliquez sur le bouton OK. (Notez que pour les autres versions du système d'exploitation, vous pouvez avoir une option Modifier, cliquez d'abord dessus, puis vous verrez l'option Ajouter ...).

Pour ce que cela vaut pour quiconque a la variante particulière de ce problème que j'ai eue:

• SQL Express 2008
• Visual Studio 2010 Premium

Grâce au 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 à divers utilisateurs un contrôle total sur le dossier et les fichiers, à un moment donné même à "Tout le monde". Rien n'a aidé, j'ai donc supprimé à nouveau les autorisations ajoutées.

Ce qui a finalement résolu le problème, c'est d'ouvrir l'Explorateur de serveurs dans Visual Studio, puis de se connecter au MDF et de le détacher à nouveau. Après avoir fait cela, mon application Web pourrait accéder à la base de données très bien.

PS. Les crédits vont à ce billet de blog que j'ai trouvé en recherchant sur Google ce problème particulier, déclenchant l'idée d'attacher / détacher la base de données pour résoudre le problème.

J'ai déplacé un fichier mdf de base de données 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 à l'emplacement d'origine aux fichiers déplacés et j'ai remarqué que MSSQL $ SQLEXPRESS ne s'était pas vu attribuer d'autorisations sur les fichiers dans leur nouvel emplacement. J'ai ajouté un contrôle complet pour "NT SERVICE \ MSSQL $ SQLEXPRESS" (doit inclure ce service NT) et il est très bien joint.

Il semble que le dossier Data d'origine dispose de ces autorisations et que les fichiers en héritent. Déplacez les fichiers et l'héritage s'arrête 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?

Cela ressemble à des autorisations NTFS. Cela signifie généralement que votre compte de service SQL Server a 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, quelle que soit la façon dont vous vous connectez). Êtes-vous sûr de ne pas avoir modifié les autorisations de dossier entre la connexion en tant que vous-même et la connexion en tant que sa? Si vous vous détachez et réessayez, le problème persiste-t-il?

J'ai eu le même problème lors de la connexion d'une base de données. Ce n'était pas un problème SQL, c'était un problème de compte. Allez dans le panneau de contrôle / Paramètres de contrôle de compte d'utilisateur / Réglez sur "ne jamais notifier". Enfin, redémarrez l'ordinateur et cela a fonctionné pour moi.

J'ai joint le fichier mdf en cliquant avec le bouton 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 contiennent une phrase intéressante:

Attention: soyez très sélectif lorsque vous ajoutez des utilisateurs à ces rôles. Par exemple, sysadmin correspond à dbo dans chaque base de données et équivaut à se connecter à l'aide du compte sa.

Bien sûr, ils ont aussi ceci:

Autorisations accordées aux utilisateurs et aux rôles et qui sont spécifiques à la base de données. Toutes les autorisations sont cumulatives à l'exception d'un REFUSER. Une autorisation refusée au niveau de l'utilisateur ou au niveau du rôle remplace la même autorisation accordée via d'autres appartenances aux rôles, à l'exception du rôle de serveur fixe sysadmin. (Un administrateur système conserve toutes les autorisations, même si un rôle dont il est membre dispose d'une autorisation DENY.)

Donc, si vous êtes un administrateur de domaine et dans le groupe SQL 'sysadmin', le monde devrait être votre crustacé.

Bien sûr, selon Microsoft, vous devriez jeter un coup d'œil rapide à ces deux pages:
Lien vers les conditions préalables de la base de données

Lien vers l'installation des bases de données

Vous êtes méchant et essayez de les attacher manuellement :) Sérieusement, avez-vous tous les prérequis pour la base de données AdventureWorks2008?
Je soupçonne que ce n'est qu'un autre cas de bizarrerie / bord de Microsoft, mais je peux me tromper.

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH
GO

changer pour 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 n'avait pas d'importance. J'ai ajouté à tout le monde le contrôle total des fichiers mdf et ldf, et l'attachement s'est bien passé.

J'étais confronté au même problème dans VS 2019.Si quelqu'un est toujours confronté au même problème, veuillez vous assurer que vous avez / faites les choses suivantes:

1. Vous devriez avoir SQL Express installé sur votre m / c
2. Devrait avoir SSDT installé dans VS (dans VS 2019 - assurez-vous de vérifier ce composant lors de l'installation) pour les versions précédentes - vous devez ajouter ce composant en externe
3. Ajoutez 'User Instance = True' à votre chaîne de connexion
4. Je pense que c'est facultatif - ouvrez VS et SQL Express en mode administratif et connectez-vous en tant qu'administrateur à SQL Express

Il s'agit en fait d'autorisations NTFS et d'un étrange bogue dans SQL Server. Je ne suis pas sûr que le rapport de bogue ci-dessus soit exact ou qu'il puisse faire référence à un bogue supplémentaire.

Pour résoudre ce problème sur 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. Dans le processus, j'ai utilisé l'interface utilisateur plutôt que de coller le chemin. J'ai remarqué que le chemin m'était coupé. En effet, l'utilisateur MS SQL Server (SQLServerMSSQLUser $ machinename $ SQLEXPRESS) que le logiciel ajoute pour vous n'a pas les autorisations pour accéder au dossier (dans ce cas, un dossier situé au fond de mes propres dossiers utilisateur).

Coller le chemin et continuer entraîne l'erreur ci-dessus. Donc - j'ai donné à l'utilisateur MS SQL Server des autorisations de lecture à partir du premier répertoire duquel il a été refusé (mon dossier utilisateur). J'ai alors immédiatement annulé l'opération de propagation car cela peut prendre une éternité, et j'ai à nouveau appliqué les autorisations de lecture nécessaires au sous-dossier suivant, et laissé cela se propager complètement.

Enfin, j'ai donné à l'utilisateur MS SQL Server des autorisations de modification sur les fichiers .mdf et .ldf pour la base de données.

Je peux maintenant joindre aux fichiers de la base de données.

Si vous exécutez SQL Server 2012, vous pouvez obtenir cette erreur en essayant de joindre une ancienne version d'un fichier mdf. ex un fichier mdf du serveur SQL 2008.

J'ai résolu le problème en déplaçant simplement le fichier .mdf que vous souhaitez joindre au dossier public, dans mon cas, je l'ai déplacé vers le dossier users / public. Ensuite, je l'attache à partir de là sans aucun problème. J'espère que cela t'aides.

Pour ceux qui n'ont pas pu résoudre le problème avec les autres solutions ici, le correctif suivant a fonctionné pour moi:

Accédez à votre dossier «DONNÉES» dans votre installation SQL Server, cliquez avec le bouton droit, propriétés, onglet de sécurité et ajoutez des autorisations de contrôle complet pour l'utilisateur «SERVICE RÉSEAU».

http://decoding.wordpress.com/2008/08/25/sql-server-2005-expess-how-to-fix-error-3417/

(Le lien ci-dessus est pour SQL 2005, mais cela a corrigé une installation SQL 2008 R2 pour moi).

Quelques informations supplémentaires: Ce problème est apparu pour moi après le remplacement d'un disque dur secondaire (sur lequel était l'installation SQL). 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 de données.

Dans mon cas, ce qui a résolu le problème é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-la ou connectez-vous à SQLServer avec «authentification Windows»

J'ai eu le même problème lors de la ré-attache de la base de données après l'avoir détachée et le déplacement des fichiers ldf et mdf du lecteur C vers F.

Afin de résoudre ce problème, j'ai dû ajouter le principal DROITS DU PROPRIÉTAIRE aux deux fichiers et lui ai donné un contrôle total sur eux dans l'onglet Sécurité de la boîte de dialogue Propriétés.