I am running a Lua program on a Windows 10 machine. This Windows 10 computer is networked to another Windows 10 computer and this other computer is sharing its D: drive with my computer. The shared drive is called the O: drive by my computer.
When I open a cmd window on my computer and type:
type "O:\Data\config\file.xml"
I get the contents of file.xml in my cmd window. However, if I run this same command through Lua:
f = io.popen([["type O:\Data\config\file.xml"]])
output = f:read("*l")
Then output returns as nil.
This behavior is true of any command involving the shared O: drive, not just type. Similarly, I have some bat scripts that reference the O: drive, and I call these using os.execute, but they are not able to accomplish their task (I can see they are actually executing, just not correctly). However, if I run similar commands or scripts with the local D: or C: drives, I do not have this issue.
Any ideas as to what could be different between these two calls? Is there a different way I can call the O: drive?
My Lua application was running as a service, and I determined that when it was running as a service it was running as a 'guest' user, rather than my system user. Therefore, it did not have the appropriate permissions to run.
I modified my Windows service to run as my specific user, and this resolved the issue.
Related
I'm using Windows 10 on a device that has only one SSD formatted with NFTS, the drive letter is C:\
I have an application that looks for a file located in D:\afolder\needed.file (I can't change this)
Is there a way to put the file needed.file in C:\ and create a virtual link so that this application thinks is working on D:\afolder\needed.file but transparently the OS is redirecting it to the file located in C: ?
I tried with the command
mklink /H D:\afolder\needed.file C:\needed.file
but I receive the error
Local NTFS volumes are required to complete the operation.
Maybe it is because the drive D: doesn't exist at all on the device?
Is there a way to make it work?
NOTE: The SSD of the device is formatted with NTFS and I run the command mklink with admin privileges
So I manage an office with about 150 computers.
I need to run a exe file on each of these machines.
I have placed my file to run on the network sharing drive but to run the file I will have to individually go to each computer and execute it.
I was wondering if it is possible to remotely execute the exe file on all machines in the network, (the machines are named in numbers such as xyzcompany1, xyzcompany2....).
Is it possible?
Have you looked into using PsExec?
https://learn.microsoft.com/en-us/sysinternals/downloads/psexec
My apologies for being vague with the answer the first time.
I would assume since the file is in a network shared folder you would first have to copy the file to the applicable workstation and then execute the program once copied.
To Copy Remote File:
psexec \\workstation123 -s cmd /c copy \\server21\share45\file.exe c:\localpath
Then Run It:
psexec \\workstation123 "c:\localpath\file.exe"
A client has a nas box (nas01) and a batch script to connect three drives to it at startup.
net use h: \\nas01\home\Foo /user:Foo bar
net use m: \\nas01\music /user:Foo bar
net use p: \\nas01\media /user:Foo bar
From windows Explorer clicking on M and H drive gets him into the folders. P drive fails with a cross through it.
I opened a command prompt (cmd) as administrator (right click run as administrator) and ran the batch.
It succeeded under CMD.
It failed to let the user in under Windows Explorer.
I used net use * /delete from the CMD prompt then ran the following line manually.
net use p: \\nas01\media /user:Foo bar
In cmd I can do a dir p: and see the files, I can change to p: drive, change folders and see sub folders and files. From Windows Explorer it get Nada.
A manual disconnect for each drive then re map of drives under windows explorer fixed the issue - all four drives accessible, but it leaves me with a batch file my client cant use when Windows drops the mapped drives again in the future.
Why is one side of windows (CMD) working but not useable under Windows Explorer? Any thoughts.
User has full admin rights on PC, local login, no UAC getting in the way.
I am using Windows XP Pro with Service Pack 3.
I have a .bat file that tests if various drives are available, and if they are then the bat file writes a little script that another program, an exe file, uses.
The problem is when the bat file issues the command to test if a disk is in the floppy drive, Windows generates an error and a message box. Windows is doing its own testing and pops up a message box, which halts my bat file. I don't want Windows to do the testing.
Here is a short bat file I wrote to demonstrate the problem:
#ECHO OFF
CLS
REM TEST FOR FLASH DRIVE
IF EXIST G:\NUL (
ECHO Flash Drive found
)
REM TEST FOR FLOPPY DISK IN DRIVE
IF EXIST A:\NUL (
ECHO Floppy in Drive
)
How do I test for a floppy without Windows getting in the way?
you can remove the null operator, and have it just try the A: drive. This works for windows 7 so it might work for windows xp. or you can use a power shell command that list all active drives which is
get-psdrive.
Power shell has the ability to run commands like cmd with some more built in features.
I'm using Windows 8.
How can I copy a non-shared file from another pc on my home network (another IP)?
This command can copy files, but only shared files:
copy \\{ip address}\Downloads\example C:\example_folder
copy (where and what) to (here)
I'd like something like this. But I don't know how can I copy a non-shared File? Is there a simple windows command I can run to do this?
You could try mapping a drive first and then doing the copy, then deleting the mapping. e.g.
net use x: \\computer name\share name
copy x:\Downloads\example C:\example_folder
....
net use x: /delete
where x: is the drive letter to map to locally.
If you don't have a share name, you could use the drive letter in the format of c$ for the c: drive on the remote machine or d$ for d: e.g.
net use x: \\computer name\c$
You will probably need to have a login for the remote machine. If you do, do the following.
net use x: \\computer-name\share-name password /user:username
I can't test this at the moment as I'm on my Linux machine, but give it a go as a guide.
See http://support.microsoft.com/kb/308582 for more details on mapping the drive