I have a folder on my server (Windows Server 2012 r2) that is shared with Everyone. All my users upload a plain text inventory file each day. I then have a vbscript that I scheduled to run under my Administrator credentials which deletes these files after reading them. However, I get permission denied errors when trying to delete or move the files.
Here is some simple code that fails:
Dim PathtoInventoryFiles
Dim myFSO
Dim myFile
Dim colFiles
PathtoInventoryFiles = "D:\Inventory$"
Set myFSO = CreateObject("Scripting.FileSystemObject")
Set colFiles = myFSO.GetFolder(PathtoInventoryFiles).Files
For Each myFile In colFiles
wscript.echo myFile.path
'Tried both of the following (only one at a time of course)
myFSO.DeleteFile myFile.Path 'Permission denied
myFile.Delete 'Permission denied
Next
Set myFSO = Nothing
Set colFiles = Nothing
The echo produces a correct path to a good and existing file. So I'm thinking I have a permissions issue? This is a pretty plain vanilla installation of Server 2012.
Getting a "permission denied" error on a file where the permissions already allow access usually means that the file is (still) opened by someone/something. You can check that with net file for remote connections, or handle for local processes.
Related
I have been using a particular VBScript for a long time and it suddenly broke today with a permission denied error. The line number referenced as the error points to a call to CreateTextFile as the problem. I have simplified the script to 4 lines and still get the error. Here is the simplified 4 line script:
Set objFS = CreateObject("Scripting.FileSystemObject")
Set objOutputFile = objFS.CreateTextFile("test.txt", True)
objOutputFile.WriteLine("test")
objOutputFile.Close
When I run this script I get:
Line: 2
Char: 1
Error: Permission denied
Code: 800A0046
Source: Microsoft VBScript runtime error
This is on a stand-alone Windows 10 PC, and I have changed nothing to do with user or file system permissions on my computer and have not modified the script prior to its breaking.
Just for grins, I verified that System, Administrators, and my user ID all have Full, Modify, Read & execute, List folder contents, Read, and Write permissions. That all looks good. I can copy files, delete files, open notepad and create or edit files, etc., so it doesn't seem to be a permissions problem.
It only seems to affect writing to my user profile. For example, if I run the following code, it fails in line 5, not line 2:
Set objFS = CreateObject("Scripting.FileSystemObject")
Set objOutputFile = objFS.CreateTextFile("C:\Temp\test.txt", True)
objOutputFile.WriteLine("test")
objOutputFile.Close
Set objOutputFile = objFS.CreateTextFile("C:\Users\Username\Documents\Test\test.txt", True)
objOutputFile.WriteLine("test")
objOutputFile.Close
I can work around the problem by doing the following, but I should really not have to do this:
Set objFS = CreateObject("Scripting.FileSystemObject")
Set objOutputFile = objFS.CreateTextFile("C:\Temp\test.txt", True)
objOutputFile.WriteLine("test")
objOutputFile.Close
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.run "cmd.exe /C copy ""C:\Temp\test.txt"" ""C:\Users\Username\Documents\Test\test.txt"" "
What gives? Has Microsoft changed something that broke writing files with VBScript?
Thanks!
I seem to have a peculiar issue when I call the folder.size of a folder that I have modify rights to. The files and folders with in the parent folder have inherit modify permissions. Yet when I call the size on the folder object I get a permission denied error.
Set mobjFileSystemObject = CreateObject("Scripting.FileSystemObject")
Set objTargetFolder = mobjFileSystemObject.GetFolder("D:\data")
Wscript.Echo(objTargetFolder) 'Prints the folder path "D:\data"
Wscript.Echo("size: " & objTargetFolder.Size) 'Permission denied runtime error
Under special permissions, I have read access to the attributes and Read extend Attributes.
Note: I'm running the script on a Windows 2003 server.
First off I am not a coder at all so I am probably missing something very basic.
I am writing a script that will run via GPO when our users login to some of our terminal servers to check if a specific file exists in the users home folder, if it does it should exit, if not then it should copy an .ini file from another location. Here is the script I have that is failing.
On Error Resume Next
dim shell
set shell=createobject("wscript.shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists("C:\%USERPROFILE%\AppData\Roaming\Microsoft Dynamics SL\solomon.ini") Then
Wscript.Quit
Else
objFSO.CopyFile "\\Server\sharepath\file.ini" , "C:\%USERPROFILE%\AppData\Roaming\Microsoft Dynamics SL\"
Wscript.Echo "File Copied."
End If
It just displays the File Copied echo when I run the script, no file is copied if the file is not present, and if the file is there it still ticks past it and displays the file copied text.
Edit: Tried to clean up the way it is displayed here on the forum.
Try this:
On Error Resume Next
Dim strAppDataPath
strAppDataPath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%appdata%")
With CreateObject("Scripting.FileSystemObject")
If .FileExists(strAppDataPath & "\Microsoft Dynamics SL\solomon.ini") Then
Wscript.Quit
Else
.CopyFile "\\Server\sharepath\file.ini", strAppDataPath & "\Microsoft Dynamics SL\"
Wscript.Echo "File Copied."
End If
End With
you cannot use system environment variables within the VB Strings.
expand them beforehand as specified by omegastripes and use concatenate operator to append them to your path.
Running this very simple VBS script on a Win7 Professional 64 bit and getting a Permission
denied (800A0046) error message.
Is there a way to change the OS permissions to allow for that?
Dim FSO
Set FSO = CreateObject("Scripting.FileSystemObject")
FSO.CopyFile "C:\Users\Desktop\Source\1.txt", "C:\Users\Desktop\Destination"
FSO.Close
I'll detail as much as I can so you can understand in which environment I'm working on and what I am trying to do.
I am using Nagios at work to monitor our servers. Each one of our Windows servers has NSclient++ installed on it. One of the many scripts Nagios' calling is check_updates.vbs; here 's how it goes if someone need to know:
On the Nagios' server side, we execute the following command:
/usr/lib/nagios/plugins/check_nrpe -H WindowsServerIpAddress -p 5666 -t 120 -c check_updates
When we execute that command, here is what's happening on the Windows Server:
By using the nscp service, it calls the following command, defined in the nsclient.ini file (into NSclient++ folder):
check_updates=cscript.exe //T:120 //NoLogo scripts\\check_updates.vbs
Then, it calls the check_updates.vbs script.
The local account on the Windows Server is the administrator one. We have changed nscp service's properties so that this service is called with another account, created especially for monitoring.
So, when we call the check_updates.vbs script directly on the Windows server (i.e locally), everything goes well, the script is working perfectly. But if we call it remotely, on the Nagios server, we have a simple (but deadly) error that says Permission denied.
That is why we are focusing on giving enough permissions to the monitoring-user.
After searching more and more and trying everything we could, I must say we're kinda lost right now.
The last solution I tried was to add these lines at the beginning of the script, to give the monitoring-user enough permissions to execute the script properly:
Set WshShell = WScript.CreateObject("WScript.Shell")
If WScript.Arguments.length = 0 Then
Set ObjShell = CreateObject("Shell.Application")
ObjShell.ShellExecute "wscript.exe", """" & _
WScript.ScriptFullName & """" &_
" RunAsAdministrator", , "runas", 1
End if
(I found this here)
When I use this, locally I get an [error notice*] but the script is working anyway. However, when I call the script remotely, I just have a timeout after 120s.
More info: UAC is disabled on the Windows server, and the monitoring-user has full access control on the NSclient++\scripts folder. Using the nscp service with the admin account is not the solution we are seeking for this matter.
So, am I missing something here ? Do you have any idea about this ?
Thanks for the help ! :)
[*error notice]: Invalid arguments, check help with cscript.exe check_available_updates.vbs -h
If UAC is off then it's not a UAC permission error therefore don't worry about runas.
It's also unlikely to be a file permissions problem (all admins are equal unless someone made it different).
What is likely is the different environments. You have an assumption that is true for the interactive user only. You need to log what is happening in your script (see wshshell.LogEvent(intType, strMessage [,strTarget])). If your script has
on error remove next
remove it.
Mapped drives are a problem. As are environmental variables and special folders.
Try using Runas command line command with various options (eg /env) to see if you can duplicate the behaviour.
Also run
cmd /c set > c:\set.log
and compare the output from the two ways of running it (ie with your client and direct).
Thanks for your answer Tony, I've tried your suggestions, but eventually we ended up getting around the problem.
Despite we gave the monitoring-user all permissions needed to execute this script, it was not working. So here's what we've done:
We created a bat file which contains the command-line to call check_update.vbs and to write its output into a new file:
cscript.exe //T:120 //NoLogo "C:\Program Files\NSClient++\scripts\check_updates.vbs" > "C:\Program Files\NSClient++\check_update.log"
Then, we've created a scheduled task (using the TaskScheduler) which calls the bat file every day to check for new updates.
To have the correct output in Nagios, we created another vbscript which only has to read the check_update.log file and return the appropriate value to Nagios:
Const ForReading = 1
Const rOK = 0
Const rWarning = 1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("C:\Program Files\NSClient++\check_update.log", ForReading)
FirstChar = objFile.Read(1)
Content = objFile.ReadAll
If FirstChar = "O" Then
Wscript.Echo FirstChar + Content
Wscript.Quit(rOK)
Else
WScript.Echo FirstChar + Content
End If
Wscript.Quit(rWarning)
This vbscript is really basic, since it only reads the first letter of the file to decide which value to return. Indeed, if there are no updates available, the message will always be "OK - No patches missing".
So, by calling the bat file using the SchedulerTask, we get around the fact that the monitoring-user has not enough permissions to execute the script.