Problemen met icacls en folder redirection

[YellowOnline]

Ik breek al dagenlang mijn hoofd over een idioot probleem. Wat moet ik doen? De inhoud wissen van een UserProfile. Dit gebeurt in drie stappen (per submap):

1) Ownership (via TakeOwn)

code:

TAKEOWN.EXE /F \\$Server\home$\$User\Downloads /R /D Y
SUCCESS: The file (or folder): "\\$Server\home$\$User\Downloads" now owned by user  "$ServiceAccount".
SUCCESS: The file (or folder): "\\$Server\home$\$User\Downloads\$RECYCLE.BIN" now owned by user "$ServiceAccount".
SUCCESS: The file (or folder): "\\$Server\home$\$User\Downloads\desktop.ini" now owned by user "$ServiceAccount".
SUCCESS: The file (or folder): "\\$Server\home$\$User\Downloads\$RECYCLE.BIN\desktop.ini" now owned by user "$ServiceAccount".

2) Full control (via icacls of xcacls)

code:

ICACLS.EXE \\$Server\home$\$User\Downloads /inheritance:r /GRANT:r $ServiceAccount:(OI)(CI)F /T /C
processed file: 
\\$Server\home$\$User\Downloads
\\$Server\home$\$User\Downloads\$RECYCLE.BIN: Access is denied.
\\$Server\home$\$User\Downloads\desktop.ini: Access is denied.
\\$Server\home$\$User\Downloads\$RECYCLE.BIN\*: Access is denied.
Successfully processed 1 files; Failed processing 3 files

3) Remove
Dit lukt uiteraard niet

Batchfile:

\\$Server\home$\$User\Downloads\>rmdir Documents
Access is denied.

Of uitgebreider:

PowerShell:

Remove-Item \\$Server\home$\$User\Downloads -Recurse
Remove-Item : Cannot remove item \\$Server\home$\$User\Downloads\$RECYCLE.BIN\desktop.ini: Not Enough permission to perform operation.
At line:1 char:12
+ Remove-Item <<<<  \\$Server\home$\$User\Downloads -Recurse
    + CategoryInfo          : PermissionDenied: (desktop.ini:FileInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : RemoveFileSystemItemUnAuthorizedAccess,Microsoft.PowerShell.Commands.RemoveItemCommand

Remove-Item : Directory \\$Server\home$\$User\Downloads\$RECYCLE.BIN cannot be removed because it is not empty.
At line:1 char:12
+ Remove-Item <<<<  \\$Server\home$\$User\Downloads -Recurse
    + CategoryInfo          : WriteError: ($RECYCLE.BIN:DirectoryInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : DirectoryNotEmpty,Microsoft.PowerShell.Commands.RemoveItemCommand

Remove-Item : Cannot remove item \\$Server\home$\$User\Downloads\desktop.ini: Not Enough permission to perform operation.
At line:1 char:12
+ Remove-Item <<<<  \\$Server\home$\$User\Downloads -Recurse
    + CategoryInfo          : PermissionDenied: (desktop.ini:FileInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : RemoveFileSystemItemUnAuthorizedAccess,Microsoft.PowerShell.Commands.RemoveItemCommand

Remove-Item : Directory \\$Server\home$\$User\Downloads cannot be removed because it is not empty.
At line:1 char:12
+ Remove-Item <<<<  \\$Server\home$\$User\Downloads -Recurse
    + CategoryInfo          : WriteError: (\\$Server\home$\$User\Downloads:DirectoryInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : DirectoryNotEmpty,Microsoft.PowerShell.Commands.RemoveItemCommand

Dit is een zeer beperkte samenvatting van iets waar ik al dagenlang mijn hoofd over breek aangezien de parameters meegeven in PoSh geen sinecure was en ik heel wat met escape characters heb moeten spelen ook. Maar alles is uiteindelijk ook geprobeerd in een standaard command prompt en tot zijn essentie herleidt, maar zonder resultaat: ik krijg die mappen niet weg.

I'm at a loss. Als iemand nog ideeën heeft: ik hoor het graag.

PS. De variabelen gebruikt zijn om de boel te anonymiseren. In het testen heb ik - itt. het echte script - niet met variabelen gewerkt.

[downtime]

YellowOnline schreef op dinsdag 16 augustus 2011 @ 16:30:
Ik breek al dagenlang mijn hoofd over een idioot probleem. Wat moet ik doen? De inhoud wissen van een UserProfile. Dit gebeurt in drie stappen (per submap):

1) Ownership (via TakeOwn)

code:

TAKEOWN.EXE /F \\$Server\home$\$User\Downloads /R /D Y
SUCCESS: The file (or folder): "\\$Server\home$\$User\Downloads" now owned by user  "$User".

Klopt dit wel? Met TakeOwn neemt de ingelogde user (jij dus) ownership over die map. Hoe kan er dan aangegeven worden dat user $User nu het ownership heeft? De ownership zou natuurlijk moeten gaan naar het $ServiceAccount waaraan je daarna met icacls Full Control toekent.

Of was je gewoon slordig toen je het script anonimiseerde?

[YellowOnline]

downtime schreef op dinsdag 16 augustus 2011 @ 22:41:
[...]

Klopt dit wel? Met TakeOwn neemt de ingelogde user (jij dus) ownership over die map. Hoe kan er dan aangegeven worden dat user $User nu het ownership heeft? De ownership zou natuurlijk moeten gaan naar het $ServiceAccount waaraan je daarna met icacls Full Control toekent.

Of was je gewoon slordig toen je het script anonimiseerde?

Oeps, slordig geanonimiseerd De gebruiker die TAKEOWN en ICACLS doet is inderdaad dezelfde.

(fixed overigens)

[ Voor 4% gewijzigd door YellowOnline op 17-08-2011 00:36 ]

[nilisvw]

Als je powershell gebruikt is de commando -Force ook wel handig. Ik kreeg namelijk ook access denied als ik een hele map wilde verwijderen maar wel de juiste rechten had.

[YellowOnline]

nilisvw schreef op woensdag 17 augustus 2011 @ 19:52:
Als je powershell gebruikt is de commando -Force ook wel handig. Ik kreeg namelijk ook access denied als ik een hele map wilde verwijderen maar wel de juiste rechten had.

In het script zelf gebruik ik -Force (wat je hier niet kon zien) en dat werkt al evenmin. It's driving me insane.

[YellowOnline]

Ik heb een hoop nieuwe informatie.

Het probleem ligt helemaal niet aan ICACLS - tot zover de zinnigheid van de topictitle - maar bij TAKEOWN. Er was mij daar een error code ontsnapt die ik nu, met betere logging, wel zie: ERROR: The data area passed to a system call is too small. Googlen op die error in combinatie met TAKEOWN geeft zielig weinig informatie. De error op zich komt daarentegen wel vaker voor, maar in zoveel contexten dat ik er niets mee opschiet. Maar na zelf wat testen merk ik het volgende:

Vanop de file server zelf werkt dit

code:

TAKEOWN.EXE /R /D Y /F X:\home\Gebruikersnaam

Maar dit werkt niet

code:

TAKEOWN.EXE /R /D Y /F \\localhost\x$\home\Gebruikersnaam

Eerst dacht ik dat het aan de lengte/diepte der paden zou kunnen liggen, maar dat heb ik virj eenvoudig kunnen uitsluiten. Mijn huidige denkpiste is dat TAKEOWN een probleem heeft met ofwel UNC-pad ofwel de $ die in het UNC-pad voorkomt.

[downtime]

YellowOnline schreef op vrijdag 19 augustus 2011 @ 11:16:

code:

TAKEOWN.EXE /R /D Y /F \\localhost\x$\home\Gebruikersnaam

Eerst dacht ik dat het aan de lengte/diepte der paden zou kunnen liggen, maar dat heb ik virj eenvoudig kunnen uitsluiten. Mijn huidige denkpiste is dat TAKEOWN een probleem heeft met ofwel UNC-pad ofwel de $ die in het UNC-pad voorkomt.

Ik denk dat je daar een goede aanname doet. Veel command line opdrachten uit het pre-PowerShell tijdperk kunnen niet met UNC paden omgaan. Irritant is dat sommige opdrachten er geen moeite mee hebben en andere wel en de foutmeldingen zijn niet altijd even duidelijk.

Mijn workaround voor dat soort problemen is het gebruik van NET USE om (tijdelijk) een driveletter aan de share te koppelen. Het is een lelijke workaround maar het werkt wel. Vergeet niet om de driveletter later ook weer met NET USE /D te ontkoppelen.

[YellowOnline]

downtime schreef op vrijdag 19 augustus 2011 @ 19:05:
[...]

Ik denk dat je daar een goede aanname doet. Veel command line opdrachten uit het pre-PowerShell tijdperk kunnen niet met UNC paden omgaan. Irritant is dat sommige opdrachten er geen moeite mee hebben en andere wel en de foutmeldingen zijn niet altijd even duidelijk.

Mijn workaround voor dat soort problemen is het gebruik van NET USE om (tijdelijk) een driveletter aan de share te koppelen. Het is een lelijke workaround maar het werkt wel. Vergeet niet om de driveletter later ook weer met NET USE /D te ontkoppelen.

Dat heb ik geprobeerd, zodat je ipv.

code:

\\server\home$\user\AppRoaming
\\server\home$\user\Desktop
\\server\home$\user\Documents
etc.

code:

E:\AppRoaming
E:\Desktop
E:\Documents
etc.

krijgt. Zowel geprobeerd via NET USE als met New-PsDrive: in beide gevallen laat TakeOwn zich niet vangen: als ik gewoon de naam probeer (bv. E:\Desktop) krijg ik een "File not found". Probeer ik het volledige pad (de .FullName property), dan resolved hij het vanzelf naar het UNC-pad

[alt-92]

takeown doet het alleen lokaal goed idd.
Script dus niet remote draaien maar die sectie óf remoten en op de machine zelf laten uitvoeren of het hele script lokaal draaien per server.
Is sowieso minder error-prone omdat je script ook failt als je netwerkkaart de geest geeft of je een andere netwerkstoring hebt.

[ Voor 26% gewijzigd door alt-92 op 20-08-2011 11:43 ]

[johnkeates]

Takeown doet het lokaal dan idd, maar heb je ook gekeken of je share acl's niet anders zijn dan je FS acl's?