[Windows 2003 server] Bestanden zonder eigenaar?

[highking]

Ik zit met het volgende probleem. Op een van onze servers kwam een klant er na opzegging van zijn pakket achter dat hij zijn mail nog niet had opgehaald.
Daarom heb ik zijn mailaccount vanuit de back-up software terug gezet, en in een zipje naar de klant gestuurd.

Nu wil ik echter de map met zijn account weer verwijderen, maar dit gaat niet, vermoedelijk omdat de bestanden geen eigenaar hebben... Met dir /q zie ik dat de eigenaar van bestanden in deze directory staat ingesteld op "...".

Als ik met de rechter muisknop klik op zo'n bestand, heb ik ook het tabje "Security" niet, dus zelf eigenaar worden zoals Microsoft het in diverse documenten beschrijft gaat hierdoor niet werken.

Het werkelijke probleem is dus, dat ik deze bestanden nu niet kan wissen. De foutmelding is ook erg wazig, ik krijg enkel "Access is denied, make sure the disk is not full or write protected"... juist, er is nog 40GB vrij, en het betreft een partitie op een webserver... als die write protected zou zijn zouden de andere 500 klanten hier ook last van moeten hebben

Iemand een idee hoe ik de rechten op deze bestanden kan herstellen, zodat ik ze kan verwijderen?

[F_J_K]

Als de GUI je in de steek laat is er altijd nog de goede oude commandline; takeown.exe in de resource kit + How to use Xcacls.vbs to modify NTFS permissions

[Verwijderd]

En dan doe ik nog even een schopje naar Windows Servers en Server-software

[highking]

Verwijderd schreef op vrijdag 21 maart 2008 @ 10:53:
En dan doe ik nog even een schopje naar Windows Servers en Server-software

Excuus, ik had niet echt het idee dat dit expliciet server gerelateerd was.

@F_J_K: Bedankt, ga ik eens mee stoeien

edit:
Takeown is geen succes... in eerste instantie werkte het, vervolgens verwijderde ik het bestand met "del bestandsnaam", geen problemen... behalve dan dat het bestand er nog stond!!
Nog eens "del bestandsnaam" -> access denied
Nog eens "takeown /F bestandsnaam" -> access denied

[ Voor 31% gewijzigd door highking op 21-03-2008 14:00 ]

[highking]

Het moet toch niet gekker worden...

code:

<onzichtbaar>\Users\info\MailDrafts>XCACLS.vbs mailbox.cfg /O administrator
Starting XCACLS.VBS (Version: 5.2) Script at 21-3-2008 14:06:33

Startup directory:
"<onzichtbaar>\Users\info\MailDrafts"

Arguments Used:
        Filename = "mailbox.cfg"
        /O (Change Ownership)
                administrator


 - Changing /O user/group: "administrator" to "SERVER\administrator"
Error: File/Directory "<onzichtbaar>\Users\info\MailDrafts\mailbox.cfg" not found.


Operation Complete
Elapsed Time: 6,734375 seconds.

Ending Script at 21-3-2008 14:06:39

Not found? Waarom staat het bestand er dan gewoon als ik kijk met dir of in explorer?

Edit:
Nog eens geprobeerd, nu op een bestand dat ik nog niet aan had geraakt.
XCACLS.vbs werkte naar behoren, "del bestandsnaam" gaf geen foutmelding... maar het bestand stond er nog... volgens "dir /q" echter zonder eigenaar.
Vervolgens krijg ik weer access is denied op alle acties die ik op dat bestand los probeer te laten...

[ Voor 21% gewijzigd door highking op 21-03-2008 14:27 ]

[_H_G_]

Wat is <onzichtbaar> Via een share aan het werken ipv op de server zelf?

Ook bij share beheer gekeken of er niemand meer verbinding met het bestand heeft?

[highking]

_H_G_ schreef op dinsdag 25 maart 2008 @ 08:26:
Wat is <onzichtbaar> Via een share aan het werken ipv op de server zelf?

Ook bij share beheer gekeken of er niemand meer verbinding met het bestand heeft?

Excuus, iets te veel onzichtbaar gemaakt ;-)

<onzichtbaar> is d:\mapje\domeinnaam.nl\

Gezien ik de domeinnaam in kwestie hier niet wilde posten...

[alt-92]

Kun je nog wel een SID zien?
Eventueel kun je met subinacl nog wat proberen.

[highking]

alt-92 schreef op woensdag 26 maart 2008 @ 18:39:
Kun je nog wel een SID zien?

Wedervraag: Hoe kan ik die zien?

[alt-92]

Dan heb je een mooi S-1-5-21-7923477-4829477-18020394531-534508 -achtig nummertje staan.

offtopic:
nee, dit is niet die van mij, en als de lengte goed is dan is zelfs dat puur toeval

[ Voor 39% gewijzigd door alt-92 op 28-03-2008 18:09 ]

[highking]

alt-92 schreef op vrijdag 28 maart 2008 @ 18:08:
Dan heb je een mooi S-1-5-21-7923477-4829477-18020394531-534508 -achtig nummertje staan.

offtopic:
nee, dit is niet die van mij, en als de lengte goed is dan is zelfs dat puur toeval

Hmm... het gaat hier om een bestand, en ik begrijp dat deze identifier van een gebruiker is? Net zoiets als het uid in Linux?

Met dir /q kan ik de eigenaar zien, maar die geeft '...' op deze bestanden (waar bij andere bestanden 'SERVER\Administrators' staat).

[alt-92]

Probeer eens iets als dumpsec, subinacl of dumpacl?
Die geven dan in ieder geval nog de sID weer.

[highking]

Het probleem is opgelost!

Bleek dat de backup agent van CDP de boel tegen werkte!
We hebben de service gestopt, en weg waren de bestanden... alsof de verwijder actie nog aan de gang was, maar op een of andere manier op de unlock van de backup agent zat te wachten... heel vreemd.

Bugrapportje bij R1Soft neergelegd.