SQLServer2008開発者版を使用しています。私はAdventureWorks2008データベースを接続しようとしていました。
接続しようとすると、「アクセスが拒否されました」というエラーが表示されました。イベントログによると、それはO/Sからのものです。
開くことができませんでした：ファイル番号0のファイルD：\ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdfを開くことができませんでした。OSエラー：5（アクセスが拒否されました）。
「NTFSの問題」と思いましたが、システム（および私）は両方のファイルへのアクセスを変更しています。
saとしてログインするとデータベースを正常に接続できることがわかりましたが、ユーザーアカウントが機能しません。
私は自分のマシンのローカル管理者グループのメンバーであり、SQLServerインスタンスのsysadminsロールに属しています。
なぜ私がsaとしてログインしなければならなかったのか考えてみてください。
SQL ServerManagementStudioを管理者として実行します。（右クリック->管理者として実行）私の場合はすべての奇妙なことに対処しました。
SQL SRV EXPRESS2008R2。Windows 7
コメントありがとうございます。あなた方の何人かは私を答えに導くのを手伝ってくれました。これが私が見つけたものです：
これはNTFSアクセス許可の問題であり、SQLの問題ではありませんでした。さらに、それは一種のバグのように見えます（そしてそれは繰り返し可能です）。
問題：私が使用していたアカウントには、mdfファイルとldfファイルに対するフルコントロールのNTFSアクセス許可がありました。ただし、グループメンバーシップを通じてこれらの権限がありました（ローカル管理者グループには権限があり、私のアカウントはローカル管理者のメンバーです）。（権限を確認しました）
アタッチを実行しようとすると、（私がadminsグループにいる）SQL Serverに接続すると、NTFSの問題で失敗します。
ただし、ローカル管理者グループがドメインアカウントに直接持っているのと同じファイル権限を付与すると、問題なく接続できます。
（ああ、そうです、このマシンのローカルグループをチェックし、自分のドメインアカウントが実際にローカル管理者グループのメンバーであることを確認しました）。
そのため、一部のコード（SQLServerまたはManagementStudioのいずれか）がユーザーアカウントが保持するアクセス許可をチェックするためにエラーが発生したように見えますが、ユーザーアカウントが継承するグループアクセス許可をチェックするまでには至っていません。
それは私には奇妙に聞こえますが、何度も何度も再現できるので、それが答えであると結論付けました。
更新：これをバグとして報告しました： https ：//connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited
投稿された回答に情報を追加したいのですが。
ログインしているWindowsユーザーが.mdfファイルへのアクセス許可を持つ唯一のユーザーになるため、データベースをデタッチするときは注意してください。ユーザーとAdministratorsアカウントを含む.mdfファイルが持っていた元のアクセス許可は、SQLServerMSSQLUser$<computer_name>$<instance_name>ログインしているWindowsユーザー（SQLサーバーユーザーではない）によって上書きされます。ブーム、すべての権限はそのようになりました。他の人が言っているように、.mdfファイルを右クリックして、アクセス許可を再確認してください。
SSMSを使用してデータベースに接続し（どのSQLサーバーアカウントでもかまいません）、データベースをデタッチしたため、この問題が発生しました。それを行った後、.mdfファイルへのアクセス許可を持っていたのは私のWindowsユーザーだけでした。そのため、後でsaアカウントを使用してデータベースをアタッチしようとすると、「アクセスが拒否されました」というエラーがスローされました。
元のアクセス許可をそのまま維持するには、データベースをオフラインにしてからデタッチし、次のようにこの順序でアタッチする必要があります。
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をサーバー名に変更します。
SQL ServerManagementStudioを管理者として実行します。（右クリック->管理者として実行）Windows7で動作しました-SQLServer 2008 R2
この問題はUAC（ユーザーアカウント制御）が原因ですよね？ユーザーアカウントはAdministratorsグループのメンバーですが、Windows 7のUACでは、プログラムを「管理者として」実行しない限り、管理者の操作を実行できません。これは、SQLServerやManagementStudioなどの実際のバグではありません。（ただし、単に「エラー5」と文句を言うのではなく、問題を認識して、昇格されたアクセス許可を要求する可能性があります。）
SQL2005データベースは、Windows7で次のように接続できます。
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ファイルを保存するフォルダーを右クリックし、[プロパティ]をクリックし、[セキュリティ]タブを選択し、[編集...]をクリックして、完全に制御します。お役に立てれば！
saユーザーはNTFSアカウントSQLServerMSSQLUser$<computer_name>$<instance_name>を使用して、SQLServerSQLAgentUser$<computer_name>$<instance_name>データベースファイルにアクセスします。これらのユーザーの一方または両方に権限を追加してみてください。
ユーザーに問題はないとおっしゃっていますので、問題が解決するかどうかはわかりませんが、おsa役に立てば幸いです。
私と一緒に-ウィンドウ8で実行-右クリックして[SQLServerManagerStudio]->[管理者と一緒に実行]をクリックします。->問題なく添付
簡単に修正できますが、根本的に修正できます。mdfファイルを保存したフォルダに移動するだけです。[ファイル]->[右クリック]->[プロパティ]をクリックし、ログインしているユーザーのセキュリティのファイルに完全なアクセス許可を付与します。
この問題が発生するたびに、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つのアカウントのみが「filename.mdf」ファイルへのアクセス許可を持っていることがわかります。
この問題を解決するには、[追加...]ボタンをクリックして、他のログインまたは必要な他のログインを追加し、ログインにフルコントロールを付与します。「ldf」ファイルに対してもこれを行う必要があります。このタスクが完了したら、[OK]ボタンをクリックします。（他のOSバージョンでは、[編集]オプションがある場合があります。最初にこれをクリックすると、[追加...]オプションが表示されます。）
私はsaとしてこのエラーを受け取りました。私の場合、データベースのセキュリティは重要ではありませんでした。全員にフルコントロールをmdfファイルとldfファイルに追加したところ、添付は正常に行われました。
私が持っていたこの問題の特定のバリエーションを持っている人にとって価値があることについて：
App_dataフォルダーのコンテキストメニューを使用して、デバッグ用のSQLExpressデータベースを作成しました。接続文字列（NHibernateで使用）は次のとおりです。
Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;
これにより、データベースファイルで同じ「アクセス拒否」エラーが発生しました。ある時点では「Everyone」でも、さまざまなユーザーにフォルダとファイルのフルコントロールを与えてみました。何も役に立たなかったので、追加した権限を再度削除しました。
最終的に解決したのは、Visual Studioでサーバーエクスプローラーを開き、MDFに接続して、再度切り離すことでした。それを行った後、私のWebアプリはデータベースに問題なくアクセスできました。
PS。この特定の問題をグーグルで検索しているときに見つけたこのブログ投稿にクレジットが表示され、問題を解決するためにデータベースをアタッチ/デタッチするというアイデアが生まれました。
データベースmdfをデフォルトのDataフォルダーからasp.netapp_dataフォルダーに移動し、データベースをオンラインに戻そうとしてこの問題が発生しました。
元の場所にある他のファイルデータベースのセキュリティ設定を移動したファイルと比較したところ、MSSQL$SQLEXPRESSに新しい場所のファイルへのアクセス許可が割り当てられていないことがわかりました。「NTSERVICE\MSSQL $ SQLEXPRESS」（そのNT SERVICEを含める必要があります）のフルコントロールを追加しましたが、正常に接続されました。
元のデータフォルダにはこれらの権限があり、ファイルはそれを継承しているようです。もちろん、ファイルを移動すると継承が中断されます。
app_dataフォルダーに直接作成した別のプロジェクトのmdfファイルを確認しました。MSSQL$SQLEXPRESSのアクセス許可はありません。うーん。なぜSQLExpressは一方が好きで、もう一方は好きではないのだろうか？
私はこのページを読んでいて、そこに興味深い文章があります：
注意：これらの役割にユーザーを追加するときは、慎重に選択してください。たとえば、sysadminはすべてのデータベースのdboにマップされ、saアカウントを使用してログインするのと同じです。
もちろん、彼らはこれも持っています：
ユーザーとロールに付与され、データベース固有の権限。DENYを除いて、すべての権限は累積的です。ユーザーレベルまたはロールレベルで拒否されたアクセス許可は、sysadmin固定サーバーロールを除いて、他のロールメンバーシップを介して付与された同じアクセス許可を上書きします。（システム管理者は、メンバーであるロールにDENY権限がある場合でも、すべての権限を保持します。）
したがって、ドメイン管理者であり、SQLの「sysadmin」グループに所属している場合、世界は甲殻類である必要があります。
もちろん、Microsoftによれば、次の2つのページをざっと見ておく必要があります。
データベースの前提条件へのリンク
あなたはいたずらをしていて、それらを手動で添付しようとしています:)しかし、真剣に、AdventureWorks2008データベースのすべての前提条件がありますか？
これはMicrosoftの奇妙な/エッジのケースの1つに過ぎないと思いますが、間違っている可能性があります。
これはNTFSアクセス許可のように聞こえます。これは通常、SQL Serverサービスアカウントがファイルへの読み取り専用アクセス権を持っていることを意味します（SQL Serverは、ログイン方法に関係なく、同じサービスアカウントを使用してデータベースファイルにアクセスすることに注意してください）。自分でログインしてからsaとしてログインするまでの間に、フォルダのアクセス許可を変更していませんか？切り離して再試行しても、同じ問題が発生しますか？
データベースを接続するときに同じ問題が発生しました。これはSQLの問題ではなく、アカウントの問題でした。パネルコントロール/ユーザーアカウント制御設定/「通知しない」に設定します。最後に、コンピューターを再起動すると、うまくいきました。
データベースを右クリックし、ウィザードでログファイルAdventureWorks2012_Data_log.ldfを削除して、mdfファイルを添付しました。mdfファイルは次の場所に配置されました
C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA
上記の方法は、問題を解決するのに役立ちました。
USE [master]
GO
CREATE DATABASE [DataBasename] ON
( FILENAME = N'C:\data\DataBasename.mdf' )
FOR ATTACH
GO
FOR ATTACH->FORATTACH_FORCE_REBUILD_LOGに変更します
USE [master]
GO
CREATE DATABASE [DataBasename] ON
( FILENAME = N'C:\data\DataBasename.mdf' )
FOR ATTACH_FORCE_REBUILD_LOG
GO
私はVS2019で同じ問題に直面していました。まだ同じ問題に直面している人がいる場合は、次のことを行っていることを確認してください。
SQL Server 2012を実行している場合、古いバージョンのmdfファイルを添付しようとするとこのエラーが発生する可能性があります。ex SQLServer2008のmdfファイル。
これは実際にはNTFSアクセス許可であり、SQLServerの奇妙なバグです。上記のバグレポートが正確かどうか、または追加のバグを参照している可能性があります。
Windows 7でこれを解決するために、SQL Server Management Studioを通常どおり（管理者としてではなく）実行しました。次に、MDFファイルを添付しようとしました。その過程で、パスに貼り付けるのではなく、UIを使用しました。道が途切れていることに気づきました。これは、ソフトウェアが追加するMS SQL Server（SQLServerMSSQLUser $ machinename $ SQLEXPRESS）ユーザーには、フォルダー（この場合は自分のユーザーフォルダーの奥にあるフォルダー）にアクセスするためのアクセス許可がないためです。
パスを貼り付けて続行すると、上記のエラーが発生します。つまり、MS SQL Serverのユーザーに、拒否された最初のディレクトリ（ユーザーフォルダー）から読み取る権限を付与しました。次に、伝播操作が永遠に続く可能性があるため、すぐにキャンセルし、必要な次のサブフォルダーに読み取りアクセス許可を再度適用して、それを完全に伝播させました。
最後に、MSSQLServerユーザーにデータベースの.mdfファイルと.ldfファイルへの変更権限を付与しました。
これで、データベースファイルに添付できます。
添付したい.mdfファイルをパブリックフォルダーに移動するだけで問題は解決しました。私の場合は、users/publicフォルダーに移動しました。そこから問題なく取り付けます。お役に立てれば。
ここで他の解決策で問題を修正できなかった人のために、次の修正が私のために働いた：
SQL Serverインストールの[DATA]フォルダーに移動し、右クリックして[プロパティ]、[セキュリティ]タブを選択し、[ネットワークサービス]ユーザーのフルコントロール権限を追加します。
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プリンシパルを追加し、[プロパティ]ダイアログの[セキュリティ]タブでそれらを完全に制御できるようにする必要がありました。
私はSSMS（2016）でAdventureWorks2012データベースを接続するのに苦労しました。しかし、Mohammad ElsheimyによるCodeProjectの記事から引用した、このコードで成功しました。
CREATE DATABASE AdventureWorks2012
ON PRIMARY (FILENAME='D:\Dev\SQL Server\AdventureWorks2012.mdf')
FOR ATTACH;