Seit Februar 2026 gab es Berichte, dass Benutzer von Samsung-Geräten unter Windows 11 24H2 und 25H2 Probleme haben, auf ihr Systemlaufwerk C: zuzugreifen. Nun hat Microsoft zusammen mit Samsung eine kürzlich aktualisierte Samsung-App als Verursacher ausgemacht und diese temporär aus dem Store entfernt. Zudem gibt es eine Reparaturanleitung für betroffene Nutzer.
Rückblick auf das Problem
Im Zusammenhang mit dem kumulativen Update KB5077181 für Windows 11 24H2-25H2 vom 10. Februar 2026 kamen Nutzerberichte auf, dass es bei bestimmten Geräten danach Probleme mit dem Zugriff auf das Systemlaufwerk C:\ gebe. Microsoft hatte diesbezüglich dann am 13. März 2026 im Known Issues-Abschnitt der Windows Release Health-Statusseiten von Windows 11 24H2 und 25H2 einen neuen Eintrag Microsoft received reports of loss of access to the C: drive and app failures veröffentlicht.
Microsoft waren Nutzerberichte von Fällen zugegangen, wo es auf Geräten von Samsung Probleme beim Zugriff auf das Laufwerk C: gibt, nachdem das Update KB5077181 vom 10. Feb. 2026 auf Systemen mit Windows 11 24H2/25H2 installiert wurde.
Die Probleme treten bei betroffenen Geräten auf, wenn Benutzer gängige Aktionen, wie beispielsweise auf Dateien zugreifen, Anwendungen starten oder administrative Aufgaben erledigen, ausführen. Betroffene Benutzer bekommen die Fehlermeldung "Auf C: kann nicht zugegriffen werden – Zugriff verweigert" angezeigt. Der Fehler verhindert dann den Start von Outlook, Office-Anwendungen, Webbrowser, Systemdienstprogramme und Quick Assist und/oder blockiert den Zugriff auf Dateien, die auf diesem Laufwerk liegen.
In einigen Fällen können Benutzer laut Fehlerberichten, aufgrund von Windows gemeldeter Berechtigungsfehlern zudem keine Berechtigungen erweitern, Updates deinstallieren oder Protokolle erfassen. Im Beitrag Windows 11 24H2/25H2: Feb. 2026 Update KB5077181 kann Zugriff auf C: blocken hatte ich ausgeführt, dass Nutzerberichte aus verschiedenen Ländern vorlägen und Microsoft sowie Samsung das Problem untersuchen.
Microsoft entfernt Samsung-App und nennt Details
Zum 16. März 2026 hat Microsoft im Known Issues-Abschnitt der Windows Release Health-Statusseiten von Windows 11 24H2 und 25H2 den Beitrag Microsoft received reports of loss of access to the C: drive and app failures aktualisiert. Gegenüber der initialen Beschreibung gibt Microsoft nun an, dass man mit Samsung nach gemeinsamen Untersuchungen zum Schluss gekommen sei, dass die berichteten Probleme nicht mit dem März 2026-Update zusammenhängen. Die Symptome werden durch ein Update der Samsung Galaxy Connect-App verursacht.
Das Problem wurde auf Samsung Galaxy Book 4- und Samsung-Desktop-Modellen wie NP750XGJ, NP750XGL, NP754XGJ, NP754XFG, NP754XGK, DM500SGA, DM500TDA, DM500TGA und DM501SGA beobachtet, auf denen Windows 11 in den Versionen 24H2 und 25H2 läuft.
Um zu verhindern, dass weitere Samsung Windows 11-Systeme in das Problem laufen, hat Microsoft zum 14. März 2026 vorübergehend die Samsung Galaxy Connect-App aus dem Microsoft Store entfernt. Samsung hat inzwischen eine stabile Vorgängerversion der Anwendung erneut veröffentlicht, um ein erneutes Auftreten der obigen Problem zu verhindern.
Wer bereits auf Samsung-Geräten von dem oben genannten Problem betroffen ist, kann die Anweisungen aus dem Microsoft KB-Beitrag Recovery steps: Samsung Galaxy Connect or Samsung Continuity Service might cause loss of access to the C: drive befolgen. Der Beitrag fordert zum Deinstallieren der Samsung-App auf und zeigt, wie sich die temporären Berechtigungen für das Laufwerk C:\ mit Hilfe einer zu erzeugenden .bat-Datei zuweisen lassen.
Ähnliche Artikel:
Patchday: Windows 10/11 Updates (10. Februar 2026)
Windows 11 24H2/25H2: Update KB5077181 verursacht Boot-Schleife
Windows 11 24H2/25H2: Ursache für Boot-Probleme wohl gefunden
Windows 11 24H2/25H2: Feb. 2026 Update KB5077181 kann Zugriff auf C: blocken
MVP: 2013 – 2016
Funkionieren die Befehle im Microsoft-Artikel überhaupt auf einem deutschen System?
"NT AUTHORITY" ist im deutschen Windows "NT AUTHORITÄT",
"Authenticated Users" ist "Authentifizierte Benutzer",
"Users" ist "Benutzer",
"BUILTIN" ist "VORDEFINIERT",
"everyone" ist "Jeder".
Da steht auch der Befehl "Anhalten" im Script.
Das funktioniert aber nicht.
Der richtige Befehl ist "Pause".
Microsoft sollte mal lernen, Scripte nicht maschinell übersetzen zu wollen.
Werden also die originalen englischen Bezeichnungen auch auf einem deutschen System akzeptiert?
Gelten in einem deutschen Windows englische und deutsche Bezeichnungen oder gelten nur deutsche Bezeichnungen oder darf man beide Varianten mischen?
2.
Der Befehl im Script öffnet eine Lücke gegen Applocker:
icacls c:\ /grant "NT AUTHORITY\Authenticated Users:(AD)"
Dadurch kann man Unterordner anlegen, auch solche wie "Windows " oder "Program Files ", "Program Files (x86) ", also mit falschem Space.
Das sind dann Ordner, die von Windows falsch als Betriebssystem-Ordner interpretiert werden, wo aber Benutzer Schreibrechte und Ausführungsrechte haben.
Microsoft wird das Problem nie kapieren.
3.
Im Microsoft-Artikel steht:
"Sie müssen sich mit einem Administratorkonto bei Windows anmelden."
Was ich bisher noch nicht verstanden habe:
Was ist der Unterschied, zwischen der Ausführung eines Befehls mit Adminrechten innerhalb eines Standardbenutzerkontos und der Ausführung des selben Befehls nachdem man an sich mit einem Administratorkonto eingeloggt hatte.
Also Unterschied zwischen "als Administrator ausführen" und "als Administrator einloggen". Welche zusätzliche Rechte gibt es im Fall 2?
So einen Unterschied gibt es auch bei dem "Media Creation Tool". Das funktioniert nur dann vollständig, wenn man in einem Administratorkonto eingeloggt ist. "Ausführen als Administrator" innerhalb eines Standardbenutzerkontos reicht nicht aus.
Im Microsoft-Artikl steht:
"Gilt für:
Windows 11 version 25H2, all editions Windows 11 version 24H2, all editions"
Warum betrifft das Problem angeblich nicht Windows 10?
Ist die Dateirechteeinstellung bei Windows 11 anders oder anfälliger als bei Windows 10 oder hat es vielleicht doch mit einem Windows 11-Update zu tun oder ist die Samsung-Software jetzt generell inkompatibel mit Windows 10 geworden?
So wie es da im Microsoft-Artikel steht ist es unlogisch und nicht nachvollziehbar.
Soweit mir bekannt funktionieren auch die englischen Befehle, da es keine rein "deutsche Version/anderssprachige Version" gibt. Dies sind immer orginal englische/multilinguale Versionen denen lediglich ein Sprachpaket übergestülpt wird.
Zu den anderen Punkten: ist halt Microsoft, können die einfach nicht mehr.
Die überblicken ihre Bloatware nicht mehr, passiert halt wenn amn das OS zu eierlegenden Wollmilchsau umbaut.
Das Skript funktioniert nur in einem englischen OS.
a) man ändert die MS URLs immer (!) auf en-us. das HTML ist unsauber, es wird auch Code maschinell übersetzt, der ausgeschlossen sein sollte.
b) Skripte mit Sicherheitsbezeichnern mussten schon immer lokalisiert werden, für Microsoft existiert keine andere Sprache, geschweige denn Wellknown SIDs. letztere würden immer funktionieren, aber die Unwissenden maximal verwirren
1.Zitat:
"Das Skript funktioniert nur in einem englischen OS."
[…]
"Skripte mit Sicherheitsbezeichnern mussten schon immer lokalisiert werden"
—
Dank, das dachte ich mir.
Also ist das in dem deutschen Microsoft-Artikel falsch.
2.Zitat:
"man ändert die MS URLs immer (!) auf en-us."
Das ist aber auch unlogisch, denn dort wird man dann englische Befehle finden, die laut deiner Aussage auf einem deutschen System gar nicht funktionieren.
Statt dessen muss Microsoft die Fehler im deutschen und allen anderen lokalisierten Support-Artikeln korrigieren.
Zum letzten Satz: Ist teilweise auch mein Fehler – ich haben den Microsoft-Artikel mit deren Universal-URL verlinkt, statt den en-us-Artikel per URL zu pinnen. Dadurch bekommen deutsche Besucher die Microsoft-Übersetzung, während die englischsprachige Leserschaft auf den englischen Artikel geleitet wird – die Franzosen, Spanier, Chinesen etc. bekommen ebenfalls die lokalisierte Fassung angezeigt. Ist mein Dilemma – ich habe inzwischen eine signifikante Anzahl an nicht deutschen Lesern im Blog, die per Translate-Funktion (des Blogs oder des Browsers) mitlesen. Manchmal pinne ich die URL auf den englischen Originalbeitrag, manchmal verwende ich die Universal-URL von Microsoft, die dann umleitet. Hab da noch keine einheitliche Linie für mich gefunden, wie ich die URLs hier einstelle.
in en-us hast du keine Fehler in den Befehlen, die Setup.exe ist nicht auf einmal die "setzen auf. exe"
zudem sind deutsche Verben und Worte oft sehr weit entfernt von der Technik oder dem Begriff, der im Original verwendet wird.
das Problem der SIDs ist bekannt, das war immer so.
in 98+x% der Fälle ist IMO en-us die bessere Wahl
Das Reparatur-Script mit SID statt mit lokalisierten Namen:
— Schnipp —
icacls c:\ /grant *S-1-5-32-544:(OI)(CI)(F)
icacls c:\ /grant *S-1-5-18:(OI)(CI)(F)
icacls c:\ /grant *S-1-5-32-545:(OI)(CI)(RX)
icacls c:\ /grant *S-1-5-11:(OI)(CI)(IO)(M)
icacls c:\ /grant *S-1-5-11:(AD)
icacls c:\ /setowner *S-1–5–80–956008885–3418522649–1831038044–1853292631–2271478464
icacls c:\ /remove *S-1-1-0
Pause
— Schnapp —
Quelle für SID:
*ttps://support.microsoft.com/de-de/topic/wiederherstellungsschritte-samsung-galaxy-connect-oder-samsung-continuity-service-kann-zu-einem-verlust-des-zugriffs-auf-laufwerk-c-f%C3%BChren-48c242aa-242a-4ddd-a9ad-98ea25fc04c1
Quelle für "Trusted Installer" SID:
*ttps://learn.microsoft.com/en-us/archive/msdn-magazine/2008/november/access-control-understanding-windows-file-and-registry-permissions
Beispiele:
S-1-5-32-544
Diese SID hat 4 Komponenten:
A revision level (1)
An identifier authority value (5, NT Authority)
A domain identifier (32, Builtin)
An RID (544, Administrators)
NT Authority\System
(oder auf deutsch: NT-Autorität\System):
S-1-5-18
NT-Authority\LocalService
(oder auf deutsch: NT-Autorität\LocalService):
S-1-5-19
NT Service:
S-1-5-80
Authenticated Users (NT Authority\Authenticated Users):
S-1-5-11
Administrators (BUILTIN\Administrators):
S-1-5-32-544
Users (BUILTIN\Users):
S-1-5-32-545
Jeder:
S-1-1-0
TrustedInstaller:
S-1–5–80–956008885–3418522649–1831038044–1853292631–2271478464
Korrektur für meinen Beitrag von 09:44 Uhr:
Die "Quelle für SID" sollte eigentlich folgende sein:
*ttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
Eigener Tippfehler:
"NT AUTHORITY" ist im deutschen Windows "NT AUTHORITÄT"
Das "H" im deutschen Namen ist falsch.
korrekt:
"NT AUTORITÄT"
Das Script ist echt Schrott. Anfänger… In solchen Fällen, wo man eine Lokale-unabhängige Variante braucht, macht man das mit den Well-Known-SIDs. Dementsprechend geändert kann man sich das Script aber mal für Notfälle aller Art "hinlegen".
Naja, immerhin legt es keine Schreibrechte für "c:\" für normale Benutzer an. So ist es nach obiger Änderung sogar ein bisschen für "Härtung" von Alt-Installationen zu gebrauchen, seit einigen Editionen macht es Windows ja von selbst richtig, es sei denn man weiß, wie man es über Alternate Data Streams umgehen kann. (Ein neuer Kollege hatte neulich gestaunt, wie ich auf dem von ihm eigenhändig gehärteten PC (wir wollten mal schauen was er wirklich kann) einen weiteren "c:\Windows " Ordner angelegt habe und dann trotz Applocker eigene Anwendungen ausführen konnte. (WDAC ließ sich aber nicht austricksen)