I'm trying to execute a .bat File on a Server in a local network with psexec
I'm currently trying with this command:
.\PsExec.exe -i -u Administrator \\192.168.4.36 -s -d cmd.exe -c "Z:\NX_SystemSetup\test.bat"
The server has no password (it has no internet connection and is running a clean install of Windows Server 2016), so I'm currently not entering one, and when a password is asked I simply press enter, which seems to work. Also, the .bat File currently only opens notepad on execution.
When I enter this command, I get the message "The file cannot be acessed by the system"
I've tried executing it with powershell with administrator privileges (and also without, since I saw another user on Stackoverflow mention that it only worked for them that way) but to no success.
I'm guessing this is a privilege problem, since it "can't be accessed", which would indicate to me that the file was indeed found.
I used net share in a cmd and it says that C:\ on my server is shared.
The file I'm trying to copy is also not in any kind of restricted folder.
Any ideas what else I could try?
EDIT:
I have done a lot more troubleshooting.
On the Server, I went into the firewall settings and opened TCP Port 135 and 445 explicitly, since according to google, PsExec uses these.
Also on the Server, I opened Properties of the "windows" Folder in C: and added an admin$ share, where I gave everyone all rights to the folder (stupid ik but I'm desperate for this to work)
Also played around a bunch more with different commands. Not even .\PsExec.exe \\192.168.4.36 ipconfig seems to work. I still get the same error. "The file cannot be accessed by the system"
This is honestly maddening. There is no known documentation of this error on the internet. Searching explicitly for "File cannot be accessed" still only brings up results for "File cannot be found" and similar.
I'm surely just missing something obvious. Right?
EDIT 2
I also tried adding the domain name in front of the username. I checked the domain by using set user in cmd on the server.
.\PsExec.exe \\192.168.4.16 -u DomainName\Administrator -p ~ -c "C:\Users\UserName\Documents\Mellanox Update.bat"
-p ~
seems to work for the password, so I added that.
I also tried creating a shortcut of the .bat File, and executing it as Administrator, using it instead of the original .bat File. The error stays the same "The File cannot be accessed by the system"
As additional info, the PC I'm trying to send the command from has Windows 10, the Server is running Windows Server 2016
So, the reason for this specific error is as simple and as stupid as it gets.
Turns out I was using the wrong IP. The IP I was using is an IPMI Address, which does not allow for any traffic (other than IPMI related stuff)
I have not yet gotten it to work yet, since I've run into some different errors, but the original question/problem has been resolved.
Related
I'm trying to connect to an Azure file share from my Mac running High Sierra 10.13.6 using the following command:
mount_smbfs -d 0777 -f 0777 //dolphins:PASSWORDHERE#dolphins.file.core.windows.net/models /Users/b3020111/Azure
However I keep getting the error:
mount_smbfs: server connection failed: No route to host
I have turned off packet signing in /etc/nsmb.conf:
[default]
signing_required=no
After looking around the web I seem to be at a loss as to where to go, any help is appreciated.
I got it working with azure provided connection example.
mount_smbfs -d 777 -f 777 //user:key#storageurl/folder ~/mountfolder
Folder in file share needed after url and mountfolder must exist.
But the main reason for "No route to host" was because the access key had forward slash in it! I did a rebuild of key1 until I got a key without forward slash.
BUT! Be aware, rebuilding key will kill all mounts and connections to that storageaccount.
Came across this issue myself today. Do double check that your ISP does not block SMB port 445. In my case, AT&T does actually block this port. I found this in their guide http://about.att.com/sites/broadband/network
The solution for me was to connect with a VPN which I'm already hosting on Azure. Additionally as others have mentioned in this thread, escape any / with %2f. Also, add the share name in the connection URL. For example, if your share name is my-data then the connection URL should contain xxx.file.core.windows.net/my-data.
This is omitted for some reason in the Azure docs/UI and was required for successful connection on OSX.
It was the "/" after all. I had to regenerate the key over ten times till I get a key that doesn't have the "/" character and then it worked fine through the terminal.
It should work using the following syntax:
mount_smbfs //<storage-account-name>#<storage-account-name>.file.core.windows.net/<share-name> <desired-mount-point>
Without adding the permissions.
Via Finder:
Source can be found here
"mount(2) system call failed no route to host "
while mounting azure file share on linux vm we can have this error.
In my case One package was missing which is - cifs-utils
So, I have used below command
"sudo yum install cifs-utils -y" to resolv the issue.
Important to allow port 445 (TCP) to smb communication. If you don't access it, your firewall block it! Please enable it and try it again.
I ran into this same problem, and while I was never able to get it working through the terminal I did manage to get it resolved in finder.
Essentially the same instructions as #Adam Smith-MSFT, however one key difference.
I created a directory via Azure's web interface, and after that I was able to connect by adding /<directory-name> to the connection string. Without a directory this would not work at all.
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've been working on a file server product that uses smbcilent to transfer files between client computers and the server. It's been working great so far with our LAMP (Ubuntu) server and Windows machines.
I'm currently trying to expand the setup to include Mac's, but am having trouble with the server accessing the share on the Mac.
Here's my command and error (bracketed descriptions replace private info):
# smbclient //10.101.0.7/[share-file] -U [username]%[password] -c ls
WARNING: The "syslog" option is deprecated
NTLMSSP packet check failed due to short signature (0 bytes)!
NTLMSSP NTLM2 packet check failed due to invalid signature!
session setup failed: NT_STATUS_ACCESS_DENIED
Things I've tried:
✓ Accessing share using a Windows machine to ensure the share is setup properly - check! Works fine there.
✓ Invoking -S off or --signing=off in the command - no change.
✓ Just looking at the shares first using smbclient -L 10.101.0.7 -U [username]%[password] - same error.
✓ Googling for an answer - check! Several people with similar problems, but no working solutions so far.
The most promising thing I've see so far involves compiling smbclient 4.4 from sources and running that with no authentication (-U ""%""), but that seems like a temporary solution based on a bug rather than a solid plan that will work for a long time. (But I'll try that next if I can't find any better ideas...)
Thanks for reading and trying to help!
Try adding --option="ntlmssp_client:force_old_spnego = yes" to the smbclient command as suggested on the samba-technical mailing list.
For me, this now lists shares on a Mac OSX server:
smbclient -U$user%$password -L $mac_host --option="ntlmssp_client:force_old_spnego = yes"
For mounting, you may need to add the nounix,sec=ntlmssp options as in
sudo mount -t cifs //$mac_host/$share $mountpoint -o nounix,sec=ntlmssp,username=$user,password=$password
On recent versions of MacOS (e.g. Monterey) it is necessary to do several configuration steps to enable smb access from Linux:
Open System Preferences.
Select Sharing.
Select File Sharing.
Ensure that the directory is listed in Shared Folders.
Right-click/two-finger click on the share directory.
Click on Advanced Options
Ensure Only allow SMB encrypted connections is checked.
Click OK
Click on Options
Click on the checkbox for Share files and folders using SMB.
Under Windows File Sharing ensure the appropriate user is checked.
Type the user's password in the 'Authenticate' dialog bo and press 'OK'.
Click 'Done'.
You should now be able to connect from Linux to the MacOS share using the commands given by #mivk.
EDIT: Read this first: What I was trying to do here is the result of extreme tunnel visioning, the post might be amusing, but not informative. You don't need to SSH into your own server to execute a command, what was I even thinking...
the title pretty much says it all. I want to host a CGI website on a Linux server (Debian, if it matters) and when clicking a button, perform a system command on the server itself. I'm doing this through Perl and it's Net::OpenSSH module.
Here is the problem. I can run the script through the terminal on the server itself, but only if I use sudo. It doesn't matter if the command is simply "ls". Unsurprisingly, when clicking on a button on a website which calls the module, it doesn't work either.
Here is my code:
#!/usr/bin/perl
use strict;
use warnings;
use Net::OpenSSH;
print("Content-type: text/html\n\n");
print("TEST");
my $ssh = Net::OpenSSH->new('localhost', user => 'myusername', password => 'mypassword');
$ssh->system("ls") or die "ERROR: " . $ssh->error;
print("TEST2");
When running it in the terminal using sudo, the script prints out TEST, then lists the folders in my home directory (Desktop, Documents, etc) and finally, TEST2.
When I'm not using sudo, it prints only TEST and after that this error message:
ERROR: unable to establish master SSH connection: the authenticity of
the target host can't be established; the remote host public key is
probably not present on the '~/.shh/known_hosts' file at
opensshtest.pl line 13.
I'm not using SSH keys at all, I'm trying to supply the username and password by hardcoding them into the script.
Also, when opened in a browser, it only prints out the first TEST.
Any help would be appreciated.
It's me again, the guy who posted the question. It's funny how I've spent hours trying to make this work, and stumbled upon a solution maybe an hour after posting the question here. But here it is:
I've added master_opts => [-o => "StrictKeyChecking=no"] as an additional argument to the creation of the Net::OpenSSH object (the line with user, password, etc).
I am getting a "client unknown" error when trying to commit any files from webstorm to perforce. My p4v is configured correctly and works outside of Webstorm and my p4 command line is also correctly configured yet when I use the exact same setup in webstorm I get the client unknown error. My client is setup and correctly copied into perforce. Any idea what might be going on here? Are there logs that will show me a more complete error?
For those who are facing this issue :
Check the "p4 info" output and see if "User name", "Client name" and Client are having correct data.
If they are 'none' / 'unknown', then check or set below environment variables
P4CLIENT
P4USER
P4PORT
P4CLIENT : Should match with your "workspace" name
P4USER : Username to login to perforce
P4PORT : Should have proper URL "HOSTNAME:PORT" of perforce server : Ex: 192.128.10.130:6666
I figured this out finally, though I ran into a new issue.
Resolution: The perforce client P4 (not P4v) has to be installed, and it was but it was not in the correct directory. P4 needs to be installed in your Applications on a Mac and that file needs to be made editable. You will also likely need to change your permissions for that file to allow system read/write access.
To make the file executable once it is in the Applications directory from the command prompt navigate to your applications directory and type: chmod +x p4 (http://www.perforce.com/perforce/doc.current/manuals/p4guide/01_install.html)
Then you can find the file in finder and right click it, the click get info from the context menu. From there at the very bottom will be file permissions. I set them all to read/write. You could also do this from the command line by typing chmod 755 p4 I think but I am not great on the command line so use at your own risk.
As far as your workspace is concerned that should be whatever your workspace is set to in P4V.
At that point if you hit test connection inside Webstorm->preferences->perforce it should work or at least give you a new error with some more information.
Mine was able to connect successfully but now when I try to update a file I get an error saying "path '/users/my-path.....' is not under the client's root '/users/my-path' even though the first path specified is clearly a child of the second path. Still working on this error.
Mine was able to connect successfully but now when I try to update a file I get an error saying "path '/users/my-path.....' is not under the client's root '/users/my-path' even though the first path specified is clearly a child of the second path. Still working on this error.
In my case i resolve this problem -> i had physical way to my files /Users/.... but in perforce i had a root like /users/.... (in lowercase), i change root and its help for me in mac