I am getting an error trying to automatically remove old vhd files. These are owned by the system account and I have tried multiple ways to take ownership. This is what I have so far:
Cannot convert argument "0", with value: "Administrator", for "SetOwner" to type "System.Security.Principal.IdentityReference": "Cannot convert the "Administrator" value of type "System.String"
to type "System.Security.Principal.IdentityReference"."
At C:\BackupScripts\Cleanup.ps1:11 char:34
+ $objFile = $objFile.SetOwner <<<< ($objUser)
+ CategoryInfo : NotSpecified: (:) [], MethodException
+ FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument
Set-Acl : Attempted to perform an unauthorized operation.
At C:\BackupScripts\Cleanup.ps1:12 char:13
I’ve tried entering the username as domain\administrator, but that fails as well. There must be a better way to remove the files, it does work interactively and I can delete the files with explorer. The remote share is on a Buffalo NAS with no access restrictions set.
I tried subinacl but was having a tough time passing the objects in the loop as the path parameter. It also didn’t like the /subdirectories being used with a UNC path. I’ll look into the CACLS option. Why does the script fail to delete the object when I can delete it from the command line interactively? Maybe I don’t need to set permissions. What is the difference in how windows applies the permissions in script vs interactively? Or is it the object that is different? Is there a better way to enumerate the objects that will pass them to remove-item and work?
Well, I don’t know what you’re doing interactively at the command line. There’s a lot of ways a given tool can work; the Cmd.exe “Del” command uses some fairly low-level OS APIs. The PowerShell “Remove-Item” goes through .NET. So the behavior between the two isn’t going to be identical.
There isn’t necessarily a difference in “how Windows applies permissions in script vs interactively.” What’s different are the tools you’re using. In PowerShell, you’re nearly always going through the .NET Framework unless using an external executable (like Cacls.exe). When you use the Explorer dialog box, there’s entirely different code running. It isn’t like Explorer is just running PowerShell under the hood ;). So the differences between a PowerShell command and the GUI dialog are probably massive. It isn’t like there’s one single “delete a file” mechanism in Windows that everything just calls into - unfortunately.
It isn’t how you’re enumerating the objects, either.
Think of it this way: I told you that, interactively riding a bike, I was able to get to the store. But when I got in my car, I couldn’t get there. Massively different mechanisms to accomplish the same task. Maybe my car was out of gas. Maybe my garage door was closed. There’s an entirely different thing happening with one mechanism vs the other.
Remove-item works from the shell. PS C:> remove-item ‘\backup\SBS01_backup\Friday20131129\d\WindowsImageBackup\server\Backup 2013-11-30 002622\2d398a8b-7954-11de-9c9a-806e6f6e6963.vhd’
PS C:>
But the script gets this error
PS C:\Users\wgtadmin> C:\BackupScripts\Cleanup.ps1
Remove-Item : Cannot remove item \backup\sbs01_backup\Friday20131129\c\WindowsImageBackup\server\Backup 2013-11-30 000002\2d398a8a-7954-11de-9c9a-806e6f6e6963.vhd: Access to the path is denied.
At C:\BackupScripts\Cleanup.ps1:14 char:125
You know those are two different paths, right? I’m not sure if that was supposed to be the case or not. One is point in to “D” and the other to “C.” The error you’re getting isn’t about file ownership, I don’t think. That’s “Access Denied,” not “Access to the Path Denied.” What you’re getting suggests that the path is inaccessible.
Yes the script wouldn’t get the “d” path after I had deleted the file. That’s what I’m stuck on, I suspected ownership of the vhd file.
PSMessageDetails :
Exception : System.IO.DirectoryNotFoundException: Could not find a part of the path '\\backup\sbs01_backup\Sunday20131201\c\WindowsImageBackup\server\Catalog'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOpti
on searchOption)
at System.IO.DirectoryInfo.GetDirectories(String searchPattern, SearchOption searchOption)
at Microsoft.PowerShell.Commands.FileSystemProvider.Dir(DirectoryInfo directory, Boolean recurse, Boolean nameOnly, ReturnContainers returnContainers)
TargetObject : \\backup\sbs01_backup\Sunday20131201\c\WindowsImageBackup\server\Catalog
CategoryInfo : ReadError: (\\backup\sbs01_...C-SBS01\Catalog:String) [Get-ChildItem], DirectoryNotFoundException
FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
PipelineIterationInfo : {0, 1, 26, 1}
Looks like it might just be a space. Backup Exec is getting put in soon I’m using this challenge to practice PowerShell so I really do appreciate the help.
Yeah, don’t know what to tell you but this isn’t a permissions issue, I don’t think. I mean, if Remove-Item deletes it manually, then Remove-Item should work the same from a script. No difference. It’s something in the value the script is working with.
So you try to access each successive piece of the path, one at a time, to see when it fails. Can you delete a file from \backup\sbs01_backup? Just make a little text file, and try to delete it from within a script.
In your existing script, can you - again, as a test - paste a manually typed, hardcoded path? Does it work then? Maybe copy-and-paste the path from a console session that WORKS, so you KNOW you’ve got a valid path.