{"id":6210,"date":"2011-06-11T12:44:21","date_gmt":"2011-06-11T10:44:21","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/?p=6210"},"modified":"2011-06-11T19:03:44","modified_gmt":"2011-06-11T17:03:44","slug":"betriebssystemfehler-5-zugriff-verweigert","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2011\/06\/11\/sql-talk\/sql-server\/betriebssystemfehler-5-zugriff-verweigert","title":{"rendered":"Betriebssystemfehler 5 (Zugriff verweigert)"},"content":{"rendered":"<p>Heute fiel ich auf eine echt alte Geschichte rein, die mir Dank der neuen Systemkonfiguration passierte. An meinen frisch Daheim installierten &quot;SQL Server 2008 R2&quot; wollte ich die guten alten Testdatenbanken (z.B. Pubs, Northwind und AdventureWorks) anh&#228;ngen. Ich setze erstmalig auch daheim einen 64-Bit-SQL-Server auf meinem 64-Bit-Windows-7 ein. Aber das Anh&#228;ngen wurde mit einem eigentlich eindeutigen Hinweis verweigert:<\/p>\n<blockquote><p>Meldung 5120, Ebene 16, Status 101, Zeile 1<br \/>\nDie physische Datei &#x0027;E:\\SQL-Scripts\\Data\\NORTHWND.MDF&#x0027; kann nicht ge&#246;ffnet werden. Betriebssystemfehler 5: &#x0027;5(Zugriff verweigert)&#x0027;.<\/p><\/blockquote>\n<p>Ich versuchte es zun&#228;chst &#252;ber die grafische Oberfl&#228;che und dann mittels SQL: Beides wurde abgelehnt.<\/p>\n<p>Die naheliegende L&#246;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&#246;glich.<\/p>\n<p>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&#228;tten tats&#228;chlich nicht genug Rechte gehabt. Macht es schon Klick? Ja, richtig: Schuld hat die <a href=\"http:\/\/windows.microsoft.com\/de-DE\/windows7\/products\/features\/user-account-control\">Benutzerkontensteuerung (User Account Control, UAC)<\/a>.<\/p>\n<p><strong>UAC<\/strong><\/p>\n<p>Wenn man sich an einem Rechner mit dem vordefinierten Benutzer &quot;Administrator&quot; anmeldet, dann ist die UAC generell ausgeschaltet, damit man mit solchen Problemen gar nicht erst bel&#228;stigt wird. <\/p>\n<p>Normale Benutzer, die dann durch Mitgliedschaft der Gruppe &quot;Administratoren&quot; zu Admins gemacht werden, haben damit aber zu k&#228;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.<br \/>\nBei Admin-Werkzeugen ist zum Beispiel in dem Manifest festgelegt, dass Admin-Rechte n&#246;tig sind. Man muss daher den Start best&#228;tigen, dass man hier jetzt mit Admin-Rechten unterwegs ist.<\/p>\n<p>Das war beim &quot;SQL Server Management Studio 2008 R2&quot; (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 &#252;berpr&#252;fen, dass ich im SSMS versuchte den Dienst zu stoppen: erst jetzt kam die UAC-Meldung, die Admin-Rechte erforderte.<\/p>\n<p><strong>Was hat das alles mit dem Anh&#228;ngen zu tun?<\/strong><\/p>\n<p>Der von Betriebssystem abgelehnte FileOpen wird vom SQL-Server-Prozess durchgef&#252;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&#252;hrt aber der SQL-Server eine Impersonifizierung mit dem Aufrufer beim Anh&#228;ngen von Datenbanken aus: wenn man Windows-Authentifizierung verwendet. Fr&#252;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).<\/p>\n<p><strong>Warum kam der UAC-Dialog nicht beim Assistenten zum Datenbank anh&#228;ngen?<\/strong><\/p>\n<p>Wenn man sich bspw. mit dem SA verbindet, dann f&#252;hrt der SQL-Server keine Impersonifizierung durch (wie denn auch: er wei&#223; ja nicht, welcher Windows-Benutzer dahinter steckt). Das Anh&#228;ngen wird daher mit den Rechten des Benutzers durchgef&#252;hrt in dessen Kontext der SQL-Server-Prozess l&#228;uft.<\/p>\n<p><strong>Abhilfem&#246;glichkeiten<\/strong><\/p>\n<ul>\n<li>Das &quot;SQL Server Management Studio&quot; immer mit Adminrechten starten. Dazu kann man sich eine Verkn&#252;pfung anlegen und bei der im Reiter Kompatibilit&#228;t  &quot;Programm als Administrator ausf&#252;hren&quot; festlegen.<\/li>\n<li>F&#252;r solche Dinge den &quot;SA&quot; verwenden.<\/li>\n<li>Man sorgt daf&#252;r, dass man pers&#246;nlich die n&#246;tigen Dateirechte hat, nicht nur &#252;ber die Gruppe der Administratoren geerbt.<\/li>\n<\/ul>\n<p><strong>Nicht reproduzierbar?<\/strong><\/p>\n<p>Wer das nicht reproduzieren kann, der sollte bitte die Dateirechte kontrollieren. Wenn eine Datenbank einmal angeh&#228;ngt war, dann werden die Rechte beim Trennen der Datenbank umgeschossen. Hier bekommt der &quot;Trenner&quot; Vollzugriff und dann klappt das n&#228;chste Mal freilich das Anh&#228;ngen problemlos&#8230; \ud83d\ude09  <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Heute fiel ich auf eine echt alte Geschichte rein, die mir Dank der neuen Systemkonfiguration passierte. An meinen frisch Daheim installierten &quot;SQL Server 2008 R2&quot; wollte ich die guten alten Testdatenbanken (z.B. Pubs, Northwind und AdventureWorks) anh&#228;ngen. Ich setze erstmalig auch daheim einen 64-Bit-SQL-Server auf meinem 64-Bit-Windows-7 ein. Aber das Anh&#228;ngen wurde mit einem eigentlich [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[16],"tags":[847,496],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/6210"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=6210"}],"version-history":[{"count":9,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/6210\/revisions"}],"predecessor-version":[{"id":6267,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/6210\/revisions\/6267"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=6210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=6210"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=6210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}