I'm using the remote development feature of pycharm, and I have successfully connected and am able to do changes to the files, but when I open the terminal I get this error :
you have no permission to access the terminal. to execute commands request the full access permission from the host
Notes
The server is ubuntu 16 Linux
I am trying to run a program inside a Windows 7 guest VM from my Linux host:
VBoxManage guestcontrol Win7-64bit-Pro-VM1 run --exe "C:\Program Files\7-Zip\Uninstall.exe" --verbose --username Admin1 --password "123"
However, since the program needs elevation, I get this error:
Creating guest session as user 'VM1'...
Waiting for guest session to start...
Successfully started guest session (ID 8)
Starting guest process ...
VBoxManage: error: VERR_PROC_ELEVATION_REQUIRED
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component GuestProcessWrap, interface IGuestProcess, callee nsISupports
VBoxManage: error: Context: "WaitForArray(ComSafeArrayAsInParam(aWaitStartFlags), gctlRunGetRemainingTime(msStart, cMsTimeout), &waitResult)" at line 1470 of file VBoxManageGuestCtrl.cpp
Closing guest session ...
I tried to disable UAC on Windows 7 guest VM, but it didn't work.
Is there a solution for this problem?
I am using VirtualBox 6.0.10.
I have created an issue in bug tracker - https://www.virtualbox.org/ticket/19459
Meanwhile, you can circumvent this error by making some other app to execute your main application. For example:
vboxmanage guestcontrol w10_1 --username user --password pass start "C:\Windows\Explorer.exe" "C:\Users\user\Desktop\rufus-3.9.exe"
I recently had this problem on a few systems and it turned out to be a compatibility problem with hypervisor. I disabled hypervisor in the boot configuration editor by running bcdedit /set hypervisorlaunchtype off in an command prompt as administrator (Start Menu > Type cmd > right click command prompt and select "run as Administrator")
I rebooted the system and launched the VM. The problem was resolved.
Obviously please check you are not using the services hypervisor provides or if you face problenms you can re-enable the hypervisor launch with bcdedit /set hypervisorlaunchtype off
While I'm using PSEXEC.exe getting 'Access denied' error for remote systems.
Any idea about how to solve this?
Hi i am placing here a summary from many sources online for various solutions to "access is denied" :
most information can be found here (including requirements needed) - sysinternal help
as someone mentioned add this reg key, and then restart the computer :
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system
/v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Read this knowledge base article to learn what this does and why it is
needed
Disable firewall (note - this will leave you with out any firewall
protection)
netsh advfirewall set allprofiles state off
if target user has a blank PW and you dont want to add one, run on target:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LimitBlankPasswordUse"=dword:00000000
This didnt work for me, but i have read it did for others in a few places,
on target execute:
Start -> Run -> secpol.msc -> Local Policies -> Security Options -> Network Access: Sharing > and security model for local accounts > Classic – local users authenticate as themselves
if already in 'Classic':
move to "Guest only - .." run from elevated command prompt gpupdate \force
move back to 'Classic - .." again run from elevated command prompt gpupdate \force
This one solved my issue:
run on target from elevated command prompt "net use" look at ouput chart and for shares listed in remote column there (i only deleted the disconnected ones - you can try them all) run "net use [remote path from before list] /delete" then run 'net use \target\Admin$ /user:[user name]' enter prompt password request (if empty PW just press enter), viola should work.
I just solved an identical symptom, by creating the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy and setting it to 1. More details are available here.
This helped in my case:
cmdkey.exe /add:<targetname> /user:<username> /pass:<password>
psexec.exe \\<targetname> <remote_command>
PsExec has whatever access rights its launcher has. It runs under regular Windows access control. This means whoever launched PsExec (be it either you, the scheduler, a service etc.) does not have sufficient rights on the target machine, or the target machine is not configured correctly. The first things to do are:
Make sure the launcher of PsExec is familiar to the target machine, either via the domain or by having the same user and password defined locally on both machines.
Use command line arguments to specify a user that is known to the target machine (-u user -p password)
If this did not solve your problem, make sure the target machine meets the minimum requirements, specified here.
You can try the command
net use \\computername\ipc$ /user:adminname password
to get admin permissions on remote PC before use psexec.
I had the same problem. And after a hard work, I found a easy and full solution:
I use runas to run the script in a admin account
I use the -s parameter in psExec to run in a system account
Inside the PsExec, I login again with a admin account
You can use & to run multiples commands
Remember to replace [USERNAME], [PASSWORD], [COMPUTERNAME], [COMMAND1] and [COMMAND2] with the real values
The code looks like this:
runas /user:[USERNAME] "psexec -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2]"
If you whant to debug your script in the another machine, run the following template:
runas /user:[USERNAME] "psexec -i -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2] & pause"
Try setting this key on the target (remote) machine, and restart the machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
See: http://forum.sysinternals.com/topic10924.html and http://www.brandonmartinez.com/2013/04/24/resolve-access-is-denied-using-psexec-with-a-local-admin-account/
I just added "-с" parameter. It makes Psexec copy executable to remote machine. So it works without access errors.
I found Sophos kept placing psexec.exe into the Quarantine section. Once I authorized it, it ran fine.
I still use psexec, even on win 10. Replace the psexec.exe in the Windows 10's win32 folder with the older version to work -> I use version 2.11.0.0. The Windows 10 version I was using would only run .bat files as background/hidden process on the remote computer. Took a whole day to figure this out.
Adding the registry key from above to the remote computer helps as well:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
I found another reason PSEXEC (and other PS tools) fail - If something (...say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an "Access is Denied" error, PSLIST will give the error "Processor performance object not found on " and you'll be left in the dark as to the reason.
You can RDP in; You can access the admin$ share; You can view the drive contents remotely, etc. etc., but there's no indication that file(s) or folder(s) being hidden is the reason.
I'll be posting this information on several pages that i was perusing yesterday while trying to determine the cause of this odd problem, so you might see this elsewhere verbatim - just thought I'd put the word out before anyone else pulled their hair out by the roots trying to understand why the performance counter has anything to do with PSEXEC running.
I had a case where AV was quarantining Psexec - had to disable On-access scanning
For anybody who may stumble upon this. There is a recent (Dec 2013) Security Update from Microsoft Windows on Windows 7 that is preventing remote execution.
See http://support.microsoft.com/kb/2893294/en-us
I uninstalled the Security Update by going to Control Panel\Programs\Programs and Features\Installed Updates
It worked right after that.
The following worked, but only after I upgraded PSEXEC to 2.1 from Microsoft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001 See:
http://forum.sysinternals.com/topic10924.html
I had a slightly older version that didn't work. I used it to do some USMT work via Dell kace, worked a treat :)
On Windows Server 2012 R2 I had trouble to run from user account
psexec -u administrator -p password \\machinename -h -s -d -accepteula cmd.exe
But it works fine if you run without parameters -h -s. That's why I use this to solve my trouble:
psexec -accepteula -u administrator -p password \\machinename %PathToLocalUtils%\psexec.exe -h -s -d cmd.exe
I couldn't get access to remote machines unless I had UAC disabled.
That has to be done locally, either from control panel or running the following through cmd:
reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
While UAC is enabled, make sure you run cmd as administrator.
For a different command I decided to change the network from public to work.
After trying to use the psexec command again it worked again.
So to get psexec to work try to change your network type from public to work or home.
I tried a lot of way but I could not use psexec. It gives "Access denied". After I change the target user account type from Standard to Admin, I connected the machine via psexec.
I researched the reason why admin type account is required then I found this answer.
You can change target machine user account this way: Control Panel -> User Accounts -> Change Account Type. You must enter an admin account and password to change that account if you logged in standard account.
After that I logged in with this command: psexec \\remotepcname -u remoteusername -p remotepassword cmd
Tried all suggestions above, but still was unable to resolve the error. Finally once I made the below change, I could successfully run the PSexec command.
Turns out that when you have UAC enabled psexec does not work as supposed. We need to set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0 then psexec starts working as expected.
I am using TFS to kick off PSExec to run an InstallShield process that creates installers. Our TFS build agent runs under the NETWORK SERVICE account.
I run PSExec using the -u -p options, and I am able to run the command and successfully build the installers from a command prompt against the remote machine.
However in TFS, I always get a 2250 error code and the installers don't build.
To isolate the problem, I changed the psexec command to the following...
PsExec.exe -accepteula \\<machine> -u <username> -p <password> xcopy /y c:\temp\testing.bat c:\temp\1.bat
If I run the above from the command line it copies the file. If I run the above from TFS (calling out to the above in a batch file), it fails with 2250.
So to simulate what TFS is doing I...
Started a command prompt with elevated Admin privileges
Issued psexec -i -u "nt authority\network service" cmd.exe
Ran the batch file containing the above xcopy command
So step 2 starts a command prompt using the NETWORK SERVICE account. When I run step 3 from this command prompt, I received the same 2250 error. So this is good b/c now TFS is out of the picture, and I am closer to the real issue.
Just for grins I added NETWORK SERVICE to the remote box's Administrators group. That did not solve the issue.
So here is where I am at...
If I login to the TFS box using a login in the Administrator group, open a command prompt, and run the xcopy command batch file with the -u -p parameters, everything works fine.
If I start a cmd prompt with the NETWORK SERVICE account and run the same batch file as in step 1 I get a 2250 access denied.
So in my mind the issue is clearly related to the NETWORK SERVICE account. Question is how can I get psexec to run with this account?
UPDATE
Here are the dialogs that show the NETWORK_SERVICE account in the Administrators group for and that it has full access to the path (c:\temp).
Let's say your two machines are called TFSSERVER and TARGETMACHINE.
The NetworkService on the TFS Server would be seen as the machine account, i.e. DOMAIN\TFSSERVER$, on the TARGETMACHINE. Any accounts in the NT AUTHORITY group are local accounts so it looks like you've just added TARGETMACHINE's network service as an admin, not the TFS machine's network service.
Try adding the TFS machine account to your permissions list and see if it works.
If that doesn't, look at this related question and see if anything there helps you at all: PSEXEC, access denied errors
First I will explain my target
Target - execute programs or scripts on my windows machine from my Linux machine
I find the winexe tool – this tool perform remotely executes commands on remote windows machine from my Linux – very nice,
real example about winexe tool , and how it works:
The following example syntax should open the IE on my windows machine from my Linux (very nice )
./winexe -U login%password -W WORKGROUP //remore_machine_ip "cmd /k cscript C:/open-explorer.vbs"
open-explorer.vbs script looks like that:
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "iexplore http://www.google.com", 9
So now I will explain the problem .....
Regarding the winexe syntax I see that winexe actually execute the open-explorer.vbs script but !
IE not really popup/opened? On my windows???
But when I run/exe the open-explorer.vbs script on my windows the IE (google) explorer opened successfully
So why IE opened from windows machines and not by the winexe tool?
I guess because the winexe can’t see windows ENV ? Or maybe something else?
Please advice – how to open the IE on my windows machine by winexe tool
what need to add/change/replace in my winexe syntax to open the IE on WIN ?
WINEXE tool syntax
./winexe -U login%password -W WORKGROUP //remore_machine_ip "cmd /k cscript C:/open-explorer.vbs"
login - WIN login
password - WIN password
remore_machine_ip - WIN ip address
winexe site - http://www.aldeid.com/wiki/Winexe
According to the documentation of winexe:
--interactive=0|1
Desktop interaction: 0 - disallow, 1 - allow.
If you allow use also --system switch (Win > requirement).
Vista do not support this option.
So --interactive=1 --system should do the trick.