web-dev-qa-db-ja.com

SSMS-ファイルを開けなかったため、一括読み込みできません

ネットワークロケーションを使用して一括読み込みするたびにこのエラーメッセージが表示されるユーザーがいますが、以下のエラーがスローされます。

「ファイルを開けなかったため、一括読み込みできません。オペレーティングシステムエラーコード3(このエラーのテキストを取得できませんでした。理由:15105)。」

  • ユーザーがリモートサーバーにログオンして同じクエリを実行すると、正常に動作します
  • ファイルの場所にFQDNが指定されている(\ servername\sharename\filename.txt)

  • ファイルがサーバー(C:\ドライブ)にコピーされると、クエリはSSMS経由で正常に実行されます

  • SQL Server 2008 R2を使用しています

共有フォルダのすべてのNTFSアクセス許可を確認しました。私は解決策を提案する多数の投稿を経験しましたが、運はありませんでした。

5
Jatin Patel

winerror.hはオペレーティングシステムエラーコード3をリストします as ERROR_PATH_NOT_FOUND。これはおそらく\\servername\sharename\filename.txtが存在しないか、SQL ServerサービスアカウントがUNC経由でファイルにアクセスできません。

SQL Server構成マネージャーを使用して、SQL Serverサービスアカウントの名前を確認します。

enter image description here

UNCのFileshareセキュリティをチェックして、アカウントが共有にアクセスできることを確認します。 UNCの下にあるフォルダーのファイルシステムセキュリティをチェックして、アカウントがファイルにアクセスできることを確認します。

T-SQL BULK INSERTには セキュリティアーキテクチャの理解 が必要です。そのページからの引用:

ユーザーがSQL Serverログインを使用する場合、SQL Serverプロセスアカウントのセキュリティプロファイルが使用されます。 SQL Server認証を使用したログインは、データベースエンジンの外部では認証できません。したがって、SQL Server認証を使用したログインによってBULK INSERTコマンドが開始されると、データへの接続は、SQL Serverプロセスアカウント(SQL Serverデータベースエンジンサービスによって使用されるアカウント)のセキュリティコンテキストを使用して行われます。ソースデータを正常に読み取るには、SQL Serverデータベースエンジンが使用するアカウントにソースデータへのアクセスを許可する必要があります。対照的に、SQL ServerユーザーがWindows認証を使用してログオンした場合、ユーザーは次のことができるファイルのみを読み取ることができます。 SQL Serverプロセスのセキュリティプロファイルに関係なく、ユーザーアカウントによってアクセスされます。

1台のコンピューターからsqlcmdまたはosqlを使用してBULK INSERTステートメントを実行し、2番目のコンピューターのSQL Serverにデータを挿入し、UNCパスを使用して3番目のコンピューターのdata_fileを指定すると、4861エラーが発生することがあります。

このエラーを解決するには、SQL Server認証を使用して、SQL Serverプロセスアカウントのセキュリティプロファイルを使用するSQL Serverログインを指定するか、Windowsを構成してセキュリティアカウントの委任を有効にします。ユーザーアカウントを委任に対して信頼できるようにする方法については、Windowsヘルプを参照してください。

2
Max Vernon

とすれば:

  1. ネットワーク上のファイルを使用するとエラーが発生する

  2. エラーはnotがローカルファイル(SQL Serverを実行しているサーバーに対してローカル)を使用すると発生

  3. エラーが発生notユーザーがリモートサーバーにログオンした場合にネットワーク上のファイルを使用すると発生する

私は言うでしょう:

  1. ユーザーはWindowsログインで接続しています

    ユーザーがSQL Serverログインで接続している場合、リモートサーバーからSQL Serverにログインした場合でも、リモートデスクトップ経由でサーバーから直接SQL Serverにログインした場合でも、動作は同じです。 SQL ServerログインはSQL Serverの外部(つまり、Windows/Active Directory)には存在しないため、なりすましの可能性があるセキュリティコンテキストはありません。その場合、BULK INSERT/OPENROWSET(BULK...プロセスは、SQL Serverプロセスを実行しているサービスアカウントの既存のセキュリティコンテキストを使用します。

    Windowsログインで接続する場合、偽装できるセキュリティコンテキストが存在するため、一括操作はそれを実行しようとします。ここでの問題は、転送されたセキュリティトークンは、デフォルトでは再転送できないことです。これが、ユーザーがデスクトップから接続するときにエラーを受け取る理由です(ユーザーはデスクトップにログインしてセキュリティトークンを取得し、転送されたセキュリティトークンを使用してSQL Serverにリモートでログインします)。ユーザーがリモートデスクトップ経由でリモートサーバーに直接ログインすると、そのサーバーから完全なセキュリティトークンを取得し、それを使用してSQL Serverに直接接続するので、これを使用してネットワークサービスに転送できます。共有フォルダなど。

  2. 次のいずれかが必要です。

    1. EveryoneまたはDomain Userなどの共有のアクセス許可を開く

    2. Active Directoryに移動し、委任用にそのユーザーのWindowsログインを構成します。

    3. (たぶん)EXECUTE ASステートメントのCREATE PROCEDURE句を使用して偽装できるSQL Serverユーザーを設定し、一括操作を実行するストアドプロシージャを作成します。私はこれを試していないので、それがうまくいくかどうかは完全にはわかりませんが、アイデアは、セキュリティコンテキストをSQL Serverアカウントのセキュリティコンテキストに切り替えて、一括操作が偽装ではなく、現在の操作を使用するようにすることですSQL Serverサービスアカウントのセキュリティコンテキスト。おそらく、一撃の価値があるでしょう。

0
Solomon Rutzky