データベースをアタッチするとアクセスが拒否される

SQL Server 2008開発者版を使用しています。AdventureWorks2008データベースをアタッチしようとしていました。

添付しようとすると、「アクセスが拒否されました」というエラーが表示されました。イベントログによると、それはO / Sからのものです。

開くのに失敗しました：ファイル番号0のファイルD：\ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdfを開けませんでした。OSエラー：5（アクセスが拒否されました。）

「NTFSの問題」だと思いましたが、システム（および私）は両方のファイルへの変更アクセス権を持っています。

saとしてログインすると、データベースを正常に接続できることがわかりましたが、ユーザーアカウントが機能しません。

私は自分のマシンのローカル管理者グループのメンバーであり、SQL Serverインスタンスのsysadminsロールに属しています。

なぜsaとしてログインしなければならなかったのですか？

SQL Server Management Studioを管理者として実行します。（右クリック->管理者として実行）私の場合、すべての奇妙さを処理しました。

SQL SRV EXPRESS 2008 R2。Windows 7

たくさんのコメントありがとうございます。何人かは私を答えに導いてくれました。これが私が見つけたものです：

これはNTFSアクセス許可の問題であり、SQLの問題ではありませんでした。さらに、それは一種のバグのように見えます（そしてそれは再現可能です）。

問題：私が使用していたアカウントには、mdfファイルとldfファイルに対するフルコントロールのNTFSアクセス許可がありました。ただし、グループメンバーシップを介してこれらの権限がありました（ローカル管理者グループには権限があり、私のアカウントはローカル管理者のメンバーです）。（権限を確認しました）

接続しようとすると、SQL Serverに自分（adminsグループに属している）に接続すると、NTFSの問題で失敗します。

ただし、ローカル管理者グループと同じファイルアクセス許可をドメインアカウントに直接付与すると、問題なくアタッチできます。

（ああ、そうです。このマシンのローカルグループを確認しました。ドメインアカウントがローカル管理者グループのメンバーであることを確認しました）。

そのため、一部のコード（SQL ServerまたはManagement Studioのいずれか）がユーザーアカウントが保持するアクセス許可をチェックするため、エラーが発生したように見えますが、ユーザーアカウントが継承するグループアクセス許可はチェックしていません。

奇妙に聞こえるかもしれませんが、何度も何度も再現できるので、答えだと思いました。

更新：これをバグとして報告しました：https : //connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited

投稿された回答に情報を追加したいのですが。

ログインしているWindowsユーザーが.mdfファイルへの権限を持つ唯一のユーザーになるため、データベースをデタッチするときは注意してください。ユーザーを含む.mdfファイルの元の権限SQLServerMSSQLUser$<computer_name>$<instance_name>とAdministratorsアカウントログインしているWindowsユーザー（SQLサーバーユーザーではない）によって上書きされます。ブーム、すべての権限はそのようになくなりました。他の人が言っているように、.mdfファイルを右クリックして、権限を再確認してください。

SSMSを使用してデータベースに接続し（どのsqlサーバーアカウントでもかまいません）、データベースを切断したため、この問題に遭遇しました。それを行った後、私のWindowsユーザーは.mdfファイルへのアクセス許可を持つ唯一のユーザーでした。そのため、後でsaアカウントを使用してdbを接続しようとすると、「アクセス拒否」エラーがスローされました。

元の権限を維持するには、データベースをオフラインにしてから、デタッチしてから次のようにアタッチします。

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

フォルダーにアクセス許可を追加します .mdfファイルが。

この名前を確認してください： NT Service\MSSQLSERVER

をLocationサーバー名に変更します。

この問題はUAC（ユーザーアカウント制御）が原因ですよね。ユーザーアカウントはAdministratorsグループのメンバーですが、Windows 7のUACでは、プログラムを「管理者として」実行しない限り、管理者が行うことはできません。これは、SQL ServerやManagement Studioなどの実際のバグではありません。（ただし、問題を知っている可能性があり、単に「エラー5」と文句を言うのではなく、昇格したアクセス許可を要求する可能性があります。）

SQL Server Management Studioを管理者として実行します。（右クリック->管理者として実行）Windows 7で私のために働いた-SQL Server 2008 R2

SQL2005データベースは、Windows 7で次のようにアタッチできます。

start menu >
 all program >
  Microsoft sql server 2005 >
   sql server management studio >
    right click >
     run as administrator >
      click ok

そして、アタッチされたデータベースが正常に完了しました。

sa（または任意のSQL Serverアカウント）としてログインすると、SQL Serverサービスアカウントとして機能します。自分としてログインすると、自分のアカウントの権限を持ちます。何らかの理由で適切なファイルアクセス権がありませんが、サービスアカウントにはあります。

私はこの解決策を見つけました：.mdfファイルを保存するフォルダーを右クリック-> [プロパティ]-> [セキュリティ]タブを選択し、[編集...]をクリックして、フルコントロールを与えます。お役に立てれば！

saNTFSは、ユーザーアカウントが使用するSQLServerMSSQLUser$<computer_name>$<instance_name>とSQLServerSQLAgentUser$<computer_name>$<instance_name>、データベースファイルにアクセスすること。これらのユーザーの一方または両方に権限を追加してみてください。

あなたがsaユーザーに問題はないと言っているので、があなたの問題を解決するかどうかはわかりませんが、それが役に立てば幸いです。

With me-ウィンドウ8で実行-SQL Server Manager Studio-> Run with adminをクリックします。->問題なし

それは簡単に修正できますが、根本的に、mdfファイルを保存したフォルダーに移動するだけです。ファイルを選択->右クリック->プロパティをクリックし、ログインユーザーSecurityのファイルへの完全なアクセス許可を付与します。

この問題に遭遇するたびに、SQLサーバーで設定されているデフォルトのデータベースディレクトリとは異なるディレクトリにあるデータベースをアタッチしようとしたときがありました。

さまざまなディレクトリやアカウントへのアクセス権を悪用するのではなく、SQLサーバーが検出することを期待しているディレクトリにデータファイルを移動することを強くお勧めします。

この情報も追加したかっただけです。

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

解決

2つの異なるログインがデタッチとアタッチ操作を行ったため、このエラーが発生します。そのため、デタッチされたファイルは最初のログインによって所有されていましたが、使用されたログインがmdfおよびldfファイルの所有者ではなかったため、アタッチは失敗しました。

データベースファイルをデタッチするとき、所有者はデタッチコマンドを実行した人になるため、問題を解決するには、mdfおよびldfファイルの所有者として他のログインを変更または追加する必要があります。

「filename.mdf」ファイルを右クリックしてプロパティを選択し、mdfファイルの権限を確認します。ここでは、「filename.mdf」ファイルへのアクセス許可を持っているアカウントが1つだけであることがわかります。これは、データベースをデタッチするために使用されたアカウントだからです。

この問題を解決するには、[追加...]ボタンをクリックして、他のログインまたは必要な他のログインを追加し、フルコントロールのログインを許可します。「ldf」ファイルに対してもこれを行う必要があります。このタスクを完了したら、[OK]ボタンをクリックします。（他のOSバージョンでは、編集オプションがある場合があります。最初にこれをクリックすると、追加...オプションが表示されます。）

私が持っていたこの問題の特定のバリエーションを持つ誰にとっても価値があるもののために：

• SQL Express 2008
• Visual Studio 2010 Premium

App_dataフォルダーのコンテキストメニューを使用して、デバッグ用のSQL Expressデータベースを作成しました。（NHibernateで使用される）接続文字列は次のとおりです。

Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;

これにより、データベースファイルで同じ「アクセス拒否」エラーが発生しました。さまざまなユーザーにフォルダとファイルへのフルコントロールを、「Everyone」に対しても一度に与えてみました。何も役に立たなかったので、追加した権限をもう一度削除しました。

最終的に解決したのは、Visual Studioでサーバーエクスプローラーを開き、MDFに接続して、再度切り離すことでした。それを行った後、私のWebアプリはデータベースに問題なくアクセスできました。

PS。クレジットは、この特定の問題をグーグル検索しているときに私が見つけたこのブログ投稿に移動し、問題を解決するためにデータベースをアタッチ/デタッチするアイデアを引き起こしました。

データベースのmdfをデフォルトのDataフォルダーからasp.net app_dataフォルダーに移動したところ、データベースをオンラインに戻そうとしてこの問題が発生しました。

元の場所にある他のファイルデータベースのセキュリティ設定を移動したファイルと比較したところ、MSSQL $ SQLEXPRESSには新しい場所にあるファイルへのアクセス許可が割り当てられていないことがわかりました。"NT SERVICE \ MSSQL $ SQLEXPRESS"のフルコントロールを追加し（NTサービスを含める必要があります）、問題なく接続しました。

元のDataフォルダーにはこれらの権限があり、ファイルはそれを継承しているようです。もちろん、ファイルを移動し、継承を中断します。

app_dataフォルダーに直接作成した別のプロジェクトのmdfファイルをチェックしました。MSSQL $ SQLEXPRESS権限がありません。うーん。SQL Expressはなぜ一方が好きで、もう一方が好きではないのでしょうか。

これはNTFSアクセス許可のように聞こえます。これは通常、SQL Serverサービスアカウントがファイルへの読み取り専用アクセス権を持っていることを意味します（SQL Serverは、ログイン方法に関係なく、同じサービスアカウントを使用してデータベースファイルにアクセスします）。自分としてログインしてからsaとしてログインするまでの間に、フォルダのアクセス許可を変更していませんか？取り外して再試行しても、同じ問題が発生しますか？

データベースを接続するときにも同じ問題が発生しました。SQLの問題ではなく、アカウントの問題でした。パネルコントロール/ユーザーアカウント制御設定/ [通知しない]に移動します。最後に、コンピューターを再起動します。

データベースを右クリックし、ウィザードでログファイルAdventureWorks2012_Data_log.ldfを削除して、mdfファイルを添付しました。mdfファイルは次の場所に配置されました

    C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA

上記の方法は私が問題を解決するのに役立ちました。

私はこのページを読んでいて、そこに興味深い文章があります：

注意：これらのロールにユーザーを追加するときは、十分に注意してください。たとえば、sysadminはすべてのデータベースでdboにマップされ、saアカウントを使用してログインするのと同じです。

もちろん、彼らはこれも持っています：

ユーザーおよびロールに付与され、データベース固有の権限。DENYを除き、すべての権限は累積されます。ユーザーレベルまたはロールレベルで拒否されたアクセス許可は、sysadmin固定サーバーロールを除いて、他のロールメンバーシップを介して付与された同じアクセス許可を上書きします。（システム管理者は、メンバーである役割がDENY権限を持っている場合でも、すべての権限を保持します。）

したがって、ドメイン管理者であり、SQLの「sysadmin」グループに属している場合、世界は甲殻類でなければなりません。

もちろん、Microsoftによると、次の2つのページをざっと見ているは​​ずです。
データベース前提条件へのリンク

データベースのインストールへのリンク

あなたはいたずらで、それらを手動でアタッチしようとしています:)でも真剣に、AdventureWorks2008データベースのすべての前提条件がありますか？
これは単なるMicrosoftの奇妙なケースであると思いますが、私は間違っている可能性があります。

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

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

saとしてこのエラーが発生しました。私の場合、データベースのセキュリティは問題ではありませんでした。全員にmdfファイルとldfファイルへのフルコントロールを追加しましたが、添付はうまくいきました。

私はVS 2019で同じ問題に直面していました。まだ同じ問題に直面している人がいる場合は、次のことを確認してください：

1. SQL Expressがm / cにインストールされている必要があります
2. 以前のバージョンのSSDTがVSにインストールされている必要があります（VS 2019では、インストール中にこのコンポーネントを確認してください）-このコンポーネントを外部で追加する必要があります
3. 接続文字列に「User Instance = True」を追加します
4. 私はそのオプションだと思います-管理モードでVSとSQL Expressを開き、SQL Expressに管理者としてログインします

これは実際にはNTFSアクセス許可であり、SQL Serverの奇妙なバグです。上記のバグレポートが正確であるかどうか、または別のバグを参照している可能性があります。

Windows 7でこれを解決するために、SQL Server Management Studioを（管理者としてではなく）通常どおりに実行しました。次に、MDFファイルを添付しようとしました。その過程で、パスに貼り付けるのではなく、UIを使用しました。私は道が私から切り離されていることに気づきました。これは、ソフトウェアが追加するMS SQL Server（SQLServerMSSQLUser $ machinename $ SQLEXPRESS）ユーザーに、フォルダー（この場合、自分のユーザーフォルダーの深いフォルダー）にアクセスするためのアクセス許可がないためです。

パスを貼り付けて続行すると、上記のエラーが発生します。だから-私はMS SQL Serverのユーザーに、拒否された最初のディレクトリ（ユーザーフォルダー）から読み取る権限を与えました。その後、永遠にかかる可能性があるため、すぐに伝達操作をキャンセルし、必要な次のサブフォルダーに再度読み取りアクセス許可を適用し、それを完全に伝達させました。

最後に、MS SQL Serverユーザーに、dbの.mdfファイルと.ldfファイルに対する変更権限を与えました。

これで、データベースファイルにアタッチできます。

SQL Server 2012を実行している場合、古いバージョンのmdfファイルを添付しようとすると、このエラーが発生します。SQL Server 2008のmdfファイルの例。

パブリックフォルダーに添付する.mdfファイルを移動するだけで問題を解決しました。私の場合は、users / publicフォルダーに移動しました。そこから問題なく取り付けます。お役に立てれば。

ここで他の解決策で問題を修正できなかった人のために、次の修正が私のために働きました：

SQL Serverインストールの "DATA"フォルダーに移動し、右クリック、プロパティ、[セキュリティ]タブを選択して、 "NETWORK SERVICE"ユーザーにフルコントロールのアクセス許可を追加します。

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

（上記のリンクはSQL 2005用ですが、これによりSQL 2008 R2のインストールが修正されました）。

いくつかの追加情報：この問題は、（SQLがインストールされていた）セカンダリハードドライブを交換した後に発生しました。すべてのファイルをコピーし、元のドライブ文字を新しいハードディスクに復元しました。ただし、セキュリティ権限はコピーされませんでした。次回は、より良い方法でデータをコピーするつもりです。

私の場合、問題を解決したのは次のとおりです：

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

データベースを他のフォルダにコピーし、「Windows認証」でSQLServerにアタッチまたはログインします。

データベースをデタッチし、ldfファイルとmdfファイルをドライブCからFに移動した後、データベースを再アタッチすると、同じ問題が発生しました。

これを修正するには、両方のファイルにOWNER RIGHTSプリンシパルを追加し、[プロパティ]ダイアログの[セキュリティ]タブでそれらを完全に制御できるようにする必要がありました。