Der Zugriff auf den Pfad 'c: \ some \ path' wird für MSSQL CLR verweigert

Ich denke, dies ist ein Berechtigungsproblem, aber ich habe Probleme, es zu finden.

Ich habe eine Gruppe von CLRs auf einem Server (SQL Server 2016) und sie funktionieren wie sie sollten. Alle sind als UNSICHER gekennzeichnet und führen verschiedene Arten von Datei-E / A aus (Lesen, Schreiben, Kopieren, Verschieben, Umbenennen usw.). Ich kann sie über SSMS oder von einem Job aus genauso einfach ausführen.

Ich muss sie auf einem anderen Server installieren (auch SQL Server 2016). Mit dem ursprünglichen Visual Studio-Projekt habe ich sie auf dem neuen Server bereitgestellt. Sie werden in SSMS angezeigt. Dieser Teil sieht gut aus.

Wenn ich über SSMS versuche, einen auszuführen, wird die folgende Fehlermeldung angezeigt: "Der Zugriff auf den Pfad" Der Pfad, den ich übergeben habe "wird verweigert."

Ich bin unter meinem Windows-Login bei SSMS angemeldet. Ich habe Berechtigungen für die Datenbank, ich bin dbo. Ich bin ein Administrator auf dem Server. Ich habe Berechtigungen im Dateisystem.

Was könnte ich sonst noch vermissen?

Ich habe Berechtigungen für die Datenbank, ich bin dbo. Ich bin ein Administrator auf dem Server. Ich habe Berechtigungen im Dateisystem.

Nichts davon ist normalerweise von Bedeutung. Sofern Sie (oder wer auch immer die SQLCLR-Methoden codiert hat) Identitätswechsel nicht implementiert haben, ist der für externe Vorgänge verwendete Sicherheitskontext der des Dienstkontos, auf dem SQL Server ausgeführt wird (ähnlich dem xp_cmdshellVerhalten). Dieses Konto benötigt die Berechtigung für die Pfade, auf die Sie zugreifen möchten.

Der Vollständigkeit halber in Bezug auf Dateizugriffsberechtigungen:

1. Für den lokalen Zugriff (auf der Box) ist dies so einfach wie beides
   1. das Dienstkonto (Standardverhalten) für das Datenbankmodul (dh MSSQLSERVER oder MSSQL $ InstanceName), für das eine Berechtigung erforderlich ist, oder
   2. wenn Identitätswechsel im Code implementiert wurde
      1. und wenn die Anmeldung, die den Code ausführt, eine Windows-Anmeldung ist, keine SQL Server-Anmeldung, dann ist es dieses Windows-Konto, das die Berechtigung benötigt
      2. Wenn jedoch eine SQL Server-Anmeldung verwendet wird, erfolgt der externe Zugriff weiterhin als Database Engine-Dienstkonto
2. Für den Remotezugriff (freigegebenes Laufwerk) muss möglicherweise eine eingeschränkte Delegierung eingerichtet werden (über Active Directory; einschließlich SPNs). Gute alte Kerberos Double-Hop-Ausgabe. In diesem Fall sehen Sie einen Unterschied zwischen der Anmeldung bei SQL Server von einem anderen Computer als dem Server, auf dem es ausgeführt wird, und der direkten Anmeldung bei dem Server, auf dem SQL Server ausgeführt wird, und der anschließenden Verbindung mit der lokalen SQL Server-Instanz.

Beachten Sie, dass "DENY" Vorrang vor "GRANT" hat (genau wie bei SQL Server-Berechtigungen).

Um festzustellen, ob das für den externen Zugriff verwendete Konto tatsächlich über die erforderliche Berechtigung für die Ordner und / oder Dateien verfügt:

1. Gehen Sie zu den "Eigenschaften" des betreffenden Pfads (die spezifische Datei oder der Ordner, in dem der Fehler gemeldet wird).
2. Gehen Sie zur Registerkarte "Sicherheit"
3. Klicken Sie auf die Schaltfläche "Erweitert"
4. Gehen Sie zur Registerkarte "Effektiver Zugriff"
5. Klicken Sie auf den Link "Benutzer auswählen"
6. Geben Sie in den vollen Kontonamen (zB NT Service\MSSQLSERVER)
7. Klicken Sie auf die Schaltfläche "OK"
8. Klicken Sie auf die Schaltfläche "Effektiven Zugriff anzeigen"
9. Hat dieses Konto Zugriff auf diese Ressource?

Gibt es irgendwo auf dem Pfad, auf den Sie zugreifen möchten, DENY-Berechtigungen?

AUCH Wenn der gesamte Code Dateisystemmaterial ist, muss die Assembly höchstwahrscheinlich nicht als markiert sein UNSAFEund sollte es stattdessen sein EXTERNAL_ACCESS. Es sollten nicht zu viele Dateisystemvorgänge erforderlich sein UNSAFE. Eine davon ist das Abrufen einer Liste fester Festplatten, aber nicht sicher, was noch.

Stellen Sie sicher, dass das Dienstkonto, auf dem SQL Server ausgeführt wird, Zugriff auf diese Pfade hat.

Das wird das Konto sein, das tatsächlich mit den Dateien auf der Festplatte interagiert.

Für den Fall, dass Sie alle oben genannten Wege gegangen sind, aber es hat nicht funktioniert. Nach meiner bisherigen Erfahrung können Sie versuchen, SSMS als Administrator zu öffnen .