MSSQL CLRのパス 'c：\ some \ path'へのアクセスが拒否されました
これは権限の問題だと思いますが、見つけられません。
1つのサーバー（SQL Server 2016）にCLRのグループがあり、それらは正常に機能します。すべてがUNSAFEとマークされており、さまざまなタイプのファイルI/O（読み取り、書き込み、コピー、移動、名前変更など）を実行します。 SSMSを介して、または同じように簡単にジョブから実行できます。
別のサーバー（SQL Server 2016も）にインストールする必要があります。元のVisual Studioプロジェクトを使用して、新しいサーバーに展開しました。 SSMSに表示されます。その部分はうまく見えます。
SSMSから実行しようとすると、次のエラーが発生します。「パス「渡されたパス」へのアクセスが拒否されました。」
WindowsログインでSSMSにログインしています。データベースへのアクセス許可があります。dboです。私はサーバーの管理者です。ファイルシステムで権限を持っています。
他に何が欠けているのでしょうか？
データベースへのアクセス許可があります。dboです。私はサーバーの管理者です。ファイルシステムで権限を持っています。
通常、それは重要ではありません。あなた（またはSQLCLRメソッドをコーディングした人）が偽装を実装していない限り、外部操作に使用されるセキュリティコンテキストは、SQL Serverを実行しているサービスアカウントのセキュリティコンテキストです（xp_cmdshellの動作と同様）。アクセスしようとしているパスへのアクセス許可が必要なのは、そのアカウントです。
ファイルアクセス許可に関する完全性のために：
- ローカル（ボックス上）アクセスの場合、どちらかと同じくらい簡単です。
- アクセス許可が必要なデータベースエンジン（MSSQLSERVERまたはMSSQL $ InstanceName）サービスのサービスアカウント（デフォルトの動作）、または
- 偽装がコードに実装されている場合
- andコードを実行するログインはWindowsログインであり、SQL Serverログインではないthatアクセス許可が必要なWindowsアカウント
- but SQL Serverログインが使用されていますが、外部アクセスは引き続きデータベースエンジンサービスアカウントとして行われます
- リモートアクセス（共有ドライブ）の場合、（Active Directory経由で、SPNを含めて）制約付き委任を設定する必要がある場合があります。 Good'ol Kerberosダブルホップ問題。この場合、SQL Serverを実行しているサーバー以外の別のコンピューターからSQL Serverにログインする場合と、SQL Serverを実行しているサーバーに直接ログオンしてから、ローカルSQL Serverインスタンスに接続する場合の違いがわかります。
「DENY」は「GRANT」よりも優先されることに注意してください（SQL Server権限と同様）。
外部アクセスに使用されるアカウントに、フォルダやファイルへの必要な権限が実際にあるかどうかを判断するには、次の手順を実行します。
- 問題のパスの「プロパティ」に移動します（エラーを報告している特定のファイルまたはフォルダー）
- [セキュリティ]タブに移動します
- 「詳細」ボタンをクリックします
- 「Effective Access」タブに移動します
- 「ユーザーを選択」リンクをクリックします
- 完全なアカウント名を入力してください（例：
NT Service\MSSQLSERVER） - 「OK」ボタンをクリック
- 「有効なアクセスの表示」ボタンをクリックします
- そのアカウントはそのリソースにアクセスできますか？
アクセスしようとしているパスのどこかにDENY権限がありますか？
[〜＃〜] also [〜＃〜]すべてのコードがファイルシステムに関するものである場合、おそらくアセンブリをUNSAFEとしてマークする必要はありません。代わりにEXTERNAL_ACCESSにする必要があります。 UNSAFEを必要とするファイルシステム操作は多すぎません。それらの1つは、固定ドライブのリストを取得していますが、他に何があるかわかりません。
SQLサーバーを実行しているサービスアカウントがこれらのパスにアクセスできることを確認します。
これは、実際にディスク上のファイルと対話するアカウントになります。
上記のすべての方法を実行したが、機能しなかった場合。これまでの私の経験から、SSMSをAdministratorとして開こうとするかもしれません。