Glorf IT

Heute fiel ich auf eine echt alte Geschichte rein, die mir Dank der neuen Systemkonfiguration passierte. An meinen frisch Daheim installierten "SQL Server 2008 R2" wollte ich die guten alten Testdatenbanken (z.B. Pubs, Northwind und AdventureWorks) anhängen. Ich setze erstmalig auch daheim einen 64-Bit-SQL-Server auf meinem 64-Bit-Windows-7 ein. Aber das Anhängen wurde mit einem eigentlich eindeutigen Hinweis verweigert:

Meldung 5120, Ebene 16, Status 101, Zeile 1
Die physische Datei 'E:\SQL-Scripts\Data\NORTHWND.MDF' kann nicht geöffnet werden. Betriebssystemfehler 5: '5(Zugriff verweigert)'.

Ich versuchte es zunächst über die grafische Oberfläche und dann mittels SQL: Beides wurde abgelehnt.

Die naheliegende Lösung erwies sich als unzutreffend: Der SQL-Server-Prozess hatte ausreichende Rechte auf die Dateien. Sie waren auch nicht im Zugriff durch andere Prozesse. Sogar REN, MOVE und COPY mittels xp_cmdshell war möglich.

Wie sieht es mit meinen Rechten aus? Ich bin Mitglied der lokalen Gruppe der Administratoren, die Vollzugriff auf die Dateien hat. Normale Benutzer hingegen hätten tatsächlich nicht genug Rechte gehabt. Macht es schon Klick? Ja, richtig: Schuld hat die Benutzerkontensteuerung (User Account Control, UAC).

UAC

Wenn man sich an einem Rechner mit dem vordefinierten Benutzer "Administrator" anmeldet, dann ist die UAC generell ausgeschaltet, damit man mit solchen Problemen gar nicht erst belästigt wird.

Normale Benutzer, die dann durch Mitgliedschaft der Gruppe "Administratoren" zu Admins gemacht werden, haben damit aber zu kämpfen. Obwohl man Admin ist werden erst mal alle Programme nur mit einem normalen Benutzertoken gestartet, d.h. der Prozess hat nur die Rechte von normalen Benutzern.
Bei Admin-Werkzeugen ist zum Beispiel in dem Manifest festgelegt, dass Admin-Rechte nötig sind. Man muss daher den Start bestätigen, dass man hier jetzt mit Admin-Rechten unterwegs ist.

Das war beim "SQL Server Management Studio 2008 R2" (SSMS) nicht der Fall. Beim Start kam keine UAC-Frage hoch. Daher war der Prozess nur mit normalen Benutzerrechten unterwegs (obwohl ich Admin bin). Das konnte ich auch leicht dadurch überprüfen, dass ich im SSMS versuchte den Dienst zu stoppen: erst jetzt kam die UAC-Meldung, die Admin-Rechte erforderte.

Was hat das alles mit dem Anhängen zu tun?

Der von Betriebssystem abgelehnte FileOpen wird vom SQL-Server-Prozess durchgeführt und nicht vom SSMS. Daher sollten die Benutzerrechte des Tools keine Rolle spielen, sondern nur die des SQL-Server-Prozesses. In bestimmten Situationen führt aber der SQL-Server eine Impersonifizierung mit dem Aufrufer beim Anhängen von Datenbanken aus: wenn man Windows-Authentifizierung verwendet. Früher auch noch, wenn man sich mit Named-Pipes verband und SQL-Authentifizierung verwendete. Seitdem Named-Pipes auf Shared-Memory umgeleitet wird, scheint das nicht mehr so zu sein (ich glaube seit SQL Server 2005).

Warum kam der UAC-Dialog nicht beim Assistenten zum Datenbank anhängen?

Wenn man sich bspw. mit dem SA verbindet, dann führt der SQL-Server keine Impersonifizierung durch (wie denn auch: er weiß ja nicht, welcher Windows-Benutzer dahinter steckt). Das Anhängen wird daher mit den Rechten des Benutzers durchgeführt in dessen Kontext der SQL-Server-Prozess läuft.

Abhilfemöglichkeiten

• Das "SQL Server Management Studio" immer mit Adminrechten starten. Dazu kann man sich eine Verknüpfung anlegen und bei der im Reiter Kompatibilität "Programm als Administrator ausführen" festlegen.
• Für solche Dinge den "SA" verwenden.
• Man sorgt dafür, dass man persönlich die nötigen Dateirechte hat, nicht nur über die Gruppe der Administratoren geerbt.

Nicht reproduzierbar?

Wer das nicht reproduzieren kann, der sollte bitte die Dateirechte kontrollieren. Wenn eine Datenbank einmal angehängt war, dann werden die Rechte beim Trennen der Datenbank umgeschossen. Hier bekommt der "Trenner" Vollzugriff und dann klappt das nächste Mal freilich das Anhängen problemlos… 😉

Neulich bekam ich diesen Fehler bei einem XCOPY:

C:\>xcopy E:\ToolPool g:\Backup\ToolPool /E /C /I /Q /H /R /K /Y /D
Nicht genügend Arbeitsspeicher
0 Datei(en) kopiert

Eine schnelle Überprüfung ergab, dass genug Hauptspeicher frei war, der XCopy forderte auch nur wenig an. In der Annahme die Fehlermeldung sei ungünstig übersetzt, kontrollierte ich den Plattenplatz im Ziel. Auch kein Problem.

Des Rätsels Lösung ist ebenso abwegig wie traurig: Obwohl NTFS bis zu 1024 Zeichen lange Pfade zulässt, kann XCOPY nur Dateien kopieren deren Pfadlänge 256 Zeichen nicht überschreitet. Kaum hatte ich die dort gespeicherten HTML-Dateien mit langen Namen gekürzt, klappte alles wunderbar…

Ist das ein Bug oder ein Feature? Wenn Microsoft das irgendwo dokumentiert hat, dann ist es wohl ein Feature. In der Beschreibung zu XCOPY fand ich aber keinen Hinweis darauf. Bei RoboCopy wird immerhin erwähnt, dass Pfade länger als 256 unterstützt werden.

Das scheint also ein Bug zu sein. Insbesondere, weil trotzt Angabe von Parameter "/C" sofort abgebrochen wird.