I am trying to run rsync as follows and running into error sshpass: Failed to run command: No such file or directory .I verified the source /local/mnt/workspace/common/sectool and destination directories/prj/qct/wlan_rome_su_builds are available and accessible?what am I missing?how to fix this?
username#xxx-machine-02:~$ sshpass –p 'password' rsync –progress –avz –e ssh /local/mnt/workspace/common/sectool cnssbldsw#hydwclnxbld4:/prj/qct/wlan_rome_su_builds
sshpass: Failed to run command: No such file or directory
Would that be possible for you to check whether 'rsync' works without 'sshpass'?
Also, check whether the ports used by rsync is enabled. You can find the port info via cat /etc/services | grep rsync
The first thing is to make sure that ssh connection is working smoothly. You can check this via "sudo ssh -vvv cnssbldsw#hydwclnxbld4" (please post the message). In advance, If you are to receive any messages such as "ssh: connect to host hydwclnxbld4 port 22: Connection refused", the issue is with the openssh-server (not being installed or a broken package). Let's see what you get you get for the first command
This is the third time I'm setting up Postgres on a new machine (OS X 10.9 this time), and the third time I'm having problems with the connection.
Basically, I'm at the point where I've created a database cluster and can start postgres using:
postgres -D /usr/local/pgsql/data
But I want it to run in the background as a launch daemon, so I
sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql91-server.plist
It seems like the daemon is launched successfully. But when I type psql I get the same old error message I've been dealing with every single time I try to set up Postgres:
psql: could not connect to server: No such file or directory. Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Any ideas on what might be causing this?
The psql you're running is the old version bundled by Apple in Mac OS X and added to the default PATH. Use the one from Homebrew, by fixing your path or entering the path specifically.
Alternately, explicitly connect to the server by overriding the default socket directory:
psql -h /tmp
See also:
this superuser answer
How to modify PATH for Homebrew?
Update:
In this case it looks like the server is genuinely not starting. Check the permissions on the data directory (apparently /usr/local/pgsql/data) and check the Console.app logs for relevant messages from launchd.
Update:
You must fix the permissions so the postgres user (or postgres_, depending on how you installed) has ownership. Check the launchd config file to see what user it runs as, and sudo chown -R postgres /usr/local/pgsql/data to change ownership. Replace postgres with postgres_ if that's what your launchd config says
I am trying to run a simple MPI program using MPICH over a cluster of two machines. However, one is running Fedora 17 and the other is running Debian Squeeze - not necessarily a problem, but the issue is that the two distros put their mpi execs in different directories:
When I run the following from host1:
mpiexec -hosts host2 -np 1 -wdir /home/chris/src/mpi/ ./mpitest
it fails with the following error
bash: /usr/lib/mpich2/bin/hydra_pmi_proxy: No such file or directory
This seems to be because hydra_pmi_proxy is installed in /usr/lib/mpich2/bin on the Fedora machine but in /usr/bin on the Debian machine. I assume that when I spawn the process from host1 via ssh, it expects to find hydra_pmi_proxy in the same place on host2.
The program runs ok on both machines if I just run it locally on that node - I only get a problem when trying to run it on both.
I have searched the MPICH documentation for a way to override to remote path to hydra_pmi_proxy, but to no avail.
Can I do this somehow? I thought one of the advantages of MPICH was that it can easily handle hetrogeneous hosts....
Any insights would be most appreciated!
I managed to solve this problem not installing mpich hydra and the terminal (eg apt-get install MPICH2 or hydra). But instead I downloaded the source code: http://www.mpich.org/downloads/ (being the stable version).
Then I ran the following command on the machines Master and slave: export PATH = / home / you / mpich: $ PATH (On my computer I installed on my mpich directory).
Just solved this problem!
Thanks!
This can be solved by installing MPICH via its source code and mount the installation directory in the node in the same directory as the directory on server. then use export PATH = /home/you/mpich-installation-directory/bin: $PATH only on server.
This problem can be solved in NFS configuration with: exportfs -var (in master machine).
You have your /mirror directory, but it is necessary to add the directory /usr in /etc/exports:
/usr *(rw,sync,no_subtree_check)
In the client machine, edit /etc/fstab and add:
master-ip/usr /usr nfs defaults 0 0
Save and run the command mount -a.
After run df -h to see the mounted directory from master in slave/client.
I just installed Wireshark, but when I click capture > interfaces, the dialog box appears, but it does not contain my network interface.
When click on capture > interfaces it appears as in the screenshot below. What can cause this?
This is usually caused by incorrectly setting up permissions related to running Wireshark correctly. While you can avoid this issue by running Wireshark with elevated privileges (e.g. with sudo), it should generally be avoided (see here, specifically here). This sometimes results from an incomplete or partially successful installation of Wireshark. Since you are running Ubuntu, this can be resolved by following the instructions given in this answer on the Wireshark Q&A site. In summary, after installing Wireshark, execute the following commands:
sudo dpkg-reconfigure wireshark-common
sudo usermod -a -G wireshark $USER
Then log out and log back in (or reboot), and Wireshark should work correctly without needing additional privileges. Finally, if the problem is still not resolved, it may be that dumpcap was not correctly configured, or there is something else preventing it from operating correctly. In this case, you can set the setuid bit for dumpcap so that it always runs as root.
sudo chmod 4711 `which dumpcap`
One some distros you might get the following error when you execute the command above:
chmod: missing operand after ‘4711’
Try 'chmod --help' for more information.
In this case try running
sudo chmod 4711 `sudo which dumpcap`
In Windows, with Wireshark 2.0.4, running as Administrator did not solve this for me. What did was restarting the NetGroup Packet Filter Driver (npf) service:
Open a Command Prompt with administrative privileges.
Execute the command sc query npf and verify if the service is running.
Execute the command sc stop npf followed by the command sc start npf.
Open WireShark and press F5.
Source: http://dynamic-datacenter.be/?p=1279
For *nix OSes, run wireshark with sudo privileges. You need to be superuser in order to be able to view interfaces. Just like running tcpdump -D vs sudo tcpdump -D, the first one won't show any of the interfaces, won't compalain/prompt for sudo privileges either.
So, from terminal, run:
$ sudo wireshark
As described in other answer, it's usually caused by incorrectly setting up permissions related to running Wireshark correctly.
Windows machines:
Run Wireshark as administrator.
By Restarting NPF, I can see the interfaces with wireshark 1.6.5
Open a Command Prompt with administrative privileges.
Execute the command "sc stop npf".
Then start npf by command "sc start npf".
Open WireShark.
That's it.
On Fedora 29 with Wireshark 3.0.0 only adding a user to the wireshark group is required:
sudo usermod -a -G wireshark $USER
Then log out and log back in (or reboot), and Wireshark should work correctly.
I hit the same problem on my laptop(win 10) with Wireshark(version 3.2.0), and I tried all the above solutions but unfortunately don't help.
So,
I uninstall the Wireshark bluntly and reinstall it.
After that, this problem solved.
Putting the solution here, and wish it may help someone......
Just uninstall NPCAP and install wpcap. This will fix the issue.
I am trying
sudo mount -t cifs //<server>/<share> -o username=user#domain,password=**** /mnt/<mountpoint>
error message:
mount: wrong fs type, bad option, bad superblock on //server/share,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
The syslog has
CIFS VFS: cifs_mount failed w/return code = -22
I am able to mount the same share on another centos system. I can ping the server, mount point directory has been created.
I ran into this problem when using a host name and solved it by using an IP address. E.g.:
use
mount -t cifs //192.168.1.15/share
rather than
mount -t cifs //servername/share
Another possible solution is to install
cifs-utils
.
Ah, the dreaded -22. Basically this seems to be used as a catchall for "something didn't work", although technically it's referred to as an invalid argument.
The client does IMHO a very poor job of telling you the actual problem. (This may not be its fault - it doesn't always have access to that information).
However -- have you checked the logs on the server/machine you are connecting to?
I was connecting to an OS X samba server, and learned from what I found in the logs there that it was necessary to specify additional options under -o as follows:
nounix,sec=ntlmssp
Among the things these settings enable are "allow long names", and "ignore UNIX filename endings"...sec is to specify security flags.
Another possibility is that you're trying to access a filesystem of a type that mount.cifs can't actually handle.
For RHEL/Centos install package - "cifs-utils"
Maybe move the target?
sudo mount -t cifs -o username=user#domain,password=**** //<server>/<share> /mnt/<mountpoint>
Or maybe this solution? (Ubuntu, Debian methods)
sudo apt-get install smbfs
Or for CentOS, RedHat, Fedora try:
sudo yum install samba-client
I had a similar issue on Ubuntu 12.04 with the "mount" package (version 2.20.1-1ubuntu3).
It happened when I was trying to mount the server share using its hostname rahter than its IP.
Another way to solve the issue on Ubuntu was to install the cifs-utils package. That way I could also mount the samba share using the exact same command line (or fstab) but with hostname.
sudo mount -t cifs //hostname/share -o username=user,password=pwd /mnt/share
Just did a clean install of Ubuntu 12.04 LTS and got this trying to hook up my Linux HTPC.
Solved it by running: sudo apt-get install cifs-utils then remounting it.
CIFS returns code "-22" in many cases (not only invalid arguments).
For me installing keyutils did the trick:
apt-get install keyutils
My distribution is "Ubuntu 14.04.2 LTS".
I figured this out by increasing the logging verbosity of CIFS:
echo 7 > /proc/fs/cifs/cifsFYI
# disable again via:
#echo 0 > /proc/fs/cifs/cifsFYI
Documentation on the bitmask ("7") for cifsFYI can be found here: https://www.kernel.org/doc/readme/Documentation-filesystems-cifs-README
After trying to mount once more dmesg included more helpful information:
Dec 7 12:34:20 pc1471 kernel: [ 5442.667417] CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
Another maybe helpful link:
http://vlkan.com/blog/post/2015/01/08/smb-mount-troubleshoot/
I have Ubuntu Server 12.10 x64 installed as a VMware VM, running on OS X 10.8 (Mountain Lion).
On the Mac, in SYSTEM PREFERENCES > SHARING > FILE SHARING (on), I added a folder to share. For my tests, I created a new folder within my Public folder called "ubuntu".
In Ubuntu, I issued the following commands:
sudo mkdir /media/target
sudo mount.cifs //10.0.20.3/ubuntu /media/target -o username=davidallie,nounix,sec=ntlmssp,rw
Ubuntu prompted me for the password and, once entered, mounted the folder. I then ran:
df -H
which allowed me to verify the mounts and mount-points.
This has recently manifested thanks to a kernel bug in v5.18.8+, I was able to reproduce on v5.18.9 and v5.18.11.
Here is the relevant ticket on kernel.org, quote:
it appears that kernel 5.18.8 breaks cifs mounts on my machine. With
5.18.7, everything works fine. With 5.18.8, I am getting:
$ sudo mount /mnt/openmediavault/
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel
log messages (dmesg)
The relevant /etc/fstab line is:
//odroidxu4.local/julian /mnt/openmediavault cifs
credentials=/home/julas/.credentials,uid=julas,gid=julas,vers=3.1.1,nobrl,_netdev,auto
0 0
Here is the offending commit, and here is the fix, which applies cleanly to v5.18.11. The cause is, from what I understand, a bug in old versions of the samba server in the negotiation protocol.
If this is your issue, you can:
patch your kernel yourself;
downgrade to v5.18.7;
switch to an LTS kernel;
use the userspace (and also really slow and awful) gvfs-smb;
upgrade the samba version on your server; or
add vers=2.0 to the mount.cifs options in /etc/fstab.
Note that while I haven't tried the last one personally, the venerable #SEBiGEM has confirmed in the comments that it works for v5.18.10.
Note also that I didn't try upgrading samba on the server at all because I hate touching the box it's running on - every time I upgrade anything everything breaks. Doing so might also not be an option for those with NAS appliances.
As a personal sidenote, it's a little sad that so many different things can cause -22. My answer is correct, but very very niche and specific to this point in time. I imagine in a month it will simply be useless noise.
Just experience the problem on RHEL 5. You don't need to install the samba suite, just the samba-client and any dependencies.
Maybe it's too late, but simplest solution described in kernel bug 50631:
in the latest code, unc mount parameter in mandatory. Modified command works for me:
sudo mount -t cifs //<server>/<share> -o username=user#domain,password=****,unc=\\\\<server>\\<share> /mnt/<mountpoint>
Try run the comamnd:
$modinfo cifs
filename: /lib/modules/3.2.0-60-virtual/kernel/fs/cifs/cifs.ko
version: 1.76
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
license: GPL
author: Steve French <sfrench#us.ibm.com>
srcversion: 9435BBC2F61D29F06643803
depends:
intree: Y
vermagic: 3.2.0-60-virtual SMP mod_unload modversions 686
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int)
parm: cifs_max_pending:Simultaneous requests to server. Default: 32767 Range: 2 to 32767. (int)
parm: echo_retries:Number of echo attempts before giving up and reconnecting server. Default: 5. 0 means never reconnect. (ushort)
parm: enable_oplocks:Enable or disable oplocks (bool). Default:y/Y/1 (bool)
If your getting any error then cifs is not installed. Just check with your admin. I thought it helps out.
Adding the option vers=3.0 to the mount command worked for me: sudo mount -t cifs -v <src> <dst> -o ...,vers=3.0,...
You need to install cifs-utils first , just as follows:
sudo yum install cifs-utils
I know this is old, but on older cifs-utils versions, you may have to add the following two lines to /etc/request-key.conf
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k
Workaround without installing additional packages (cifs-utils adds another 81mb in Debian Stretch):
$ FILESERVER_IP=$(getent hosts myfileserver.com | awk '{ print $1 ; exit }')
$ sudo mount -t cifs //${FILESERVER_IP}/<share> -o username=user#domain,password=**** /mnt/<mountpoint>
Many answers, but wasn't work for me.
Solution:
My NAS didn't support Samba 3.0, on which my mount switch automatically.
So I downgraded smb version:
mount -t cifs //192.168.0.2/Share -o rw,vers=1.0,username=*****,password=******* /media/1
It's work.