New answers tagged

4

When troubleshooting problems with daemons, you should always check the system logs. In this particular case, if you check your system logs on the NAS host, you'll see something similar to: Authentication refused: bad ownership or modes for directory /home/admin The problem is shown in this output: admin@NAS:~$ ls -alh drwxrwxrwx 6 admin users 4.0K Jun ...


1

Any chance you created a password for your private key while creating it using ssh-keygen. Following is the workflow I use: ssh-keygen ssh-copy-id root@remote_host scp /test.text root@remote_host:/opt/application/


2

To answer the main question in short, rsync seems to write double the number of bytes, because it spawns two processes/threads to do the copy, and there's one stream data between the processes, and another from the receiving process to the target file. We can tell this by looking at the strace output in more detail, the process IDs in the beginning of the ...


3

Using synopsis scp host1: host2:, then the scp first connects to the first host1 and then tries to connect to the host2 from there (unfortunately not described in manual page). This means that the host2 have to be resolvable from host1 and also you need to be able to authenticate to this host from host1. There is a note in manual page for scp: -3 ...


-1

Is either NIC on either machine 1 Gbit per second? Is the switch connecting your devices 1Gbit per second? Are you using a solid state drive or a RAID so that you have an adequate disk read rate to send data at 120MB/s? Try using FTP to transfer the file instead of SCP because doing so will minimize CPU burden.


5

Looks like you're confusing Mb/s (megabit per second) with MB/s (megabyte per second). 1000 Mb/s becomes a theoretical 125 MB/s, and 120 MB/s looks like good performance (since you don't give more information, I take that it is a standard desktop PC with SATA hard disks). Besides, I don't really think you can reach 1 GB/s (which would mean 8 Gb/s) without ...


-1

scp is limited not just by your network interface speed (and indeed if you're using localhost, you're not even touching your network card), but also by disk I/O speed, CPU speed, and other mitigating factors.


0

Found the solution - host key is changed, Need to update it. update the Host key of the IP address sudo ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.2.207 After this sshfs is working, I am able to mount the complete file system.


4

I have a similar issue on one system I use (default shell is bash, I want ksh93, and chsh doesn't work). My solution, adapted for your situation, is to exec the desired shell from ~/.profile, which Dash reads on startup. Bash doesn't touch ~/.profile unless it doesn't find ~/.bash_profile or ~/.bash_login (in that order, see the Bash manual). # in ~/....


0

RSYNC behavior over SFTP Without even compressing anything, you can replicate the directory structure to the other side using LFTP (name is misleading) and the mirror subsystem of LFTP. LFTP supports SFTP and the mirror subsystem supports nearly all the capabilities of rsync. It can also split up the transfer into as many connections as you want, to make ...


2

scp is part of openssh and it does not support PuTTY key format (and current version suffers with "asking for a passphrase regardless the input). You can convert the key from PPK format using puttygen (Conversions -> Export OpenSSH), or simply create a new key in openssh format using ssh-keygen: ssh-keygen -t rsa The new key also store to the ...


0

I would start by measuring the speed of the dumbest TCP stream possible. A plain FTP (not SFTP or FTPS) would do it. If for some reason FTP doesn't work (firewalls can be an issue), try netcat. FTP just literally throws bytes at a socket. As long as it's using the full TCP packet size, and we're talking about a single file, you can't use TCP more ...


0

SCP is very simple tool to simple copy files back and forth. It was not designed to super-fast speeds and it has really small buffers on both sides. If you aim for performance, you should use sftp or rsync. About the speed measures, lets draw some diagram: [host A] --- ??? mbit --- [host B] \ / \ 300 mbit ...


0

Well as a last resort, I found an old 10/100 ethernet card from a windows 98 PC, and installed it in the server. After configuring it, I have had no more errors, over about 30 GB of data. I guess the built-in ethernet chipset didn't work well with ubuntu. Or I had somehow configured it incorrectly.


1

It is not exactly "pipe", but you can basically tell scp to copy specific FD (which can be pipe) from your host to the other. Simple bash command like this: (scp does not work as it needs a size in advance): scp <(tar cz files to compress) host:/path/to/new.file but it can work with pure ssh: tar cz files to compress | ssh host "cat > /path/to/new....


2

scp does not have this functionality. However, this can be done using rsync with the -R option. Here is the man page. rsync -aR Subject_11/subdir03 user@remote_server:/path/to/destination


0

It could be a bug in your SSH. There have been several examples of this over time. (You should definitely post the exact versions used at either end). http://www.alcatelunleashed.com/viewtopic.php?t=25294 I can't work out why a remote network path would be more reliable, or any suggestion to work on that. It can be caused by buggy network boxes though......


0

"No route to host" indicates that the problem is located on your machine and not on the target. Can you access the target IP from another host?


0

Check the firewall Iptables is allowed to the source IP, where xx.xx.xx.xx is source IP and to run below rules need root privilege, iptables -A INPUT -i eth0 -p tcp -s xx.xx.xx.xx --dport 22 -j ACCEPT Make sure SSH service is running, if not start SSH service. Also Use nmap <destination IP> to check the available opened ports.


1

Would this work for your needs? Rsync will copy the directories, files and permissions to the target directory. rsync -avz /path/to/files target_server:/path_to_files Edit: And you can add the flag to remove the original if the copy is successful.


3

Moving files (without changing their ownership) only requires being able to write to the directories containing them. So, to move /home/usera/dir1/dir2 and its contents to /home/userb/dir3, starting as usera: cd ~/dir1 find . -type d -print0 | xargs -0 chmod 777 su userb cd ~/dir3 mv ~usera/dir1/dir2 . exit then, as usera, restore the permissions to ...


1

I would do the contrary of Kupferdache: I would create a public writeable directory on my home, go to the other account and move the file to my directory, than change back the directory permission. Note: this is a real move. Then you should setup the permission as you need. So your solution with scp could be the safe one (safe and good file permissions on ...


0

Right you dont want that, so lets try something different! 1- Doing the commands as the other user without asking for password anymore: First you need to prepare your environment, so you will not need the password to do the commands. Prepare the user2: user2@machine:~$ cp /bin/bash .bash user2@machine:~$ chmod a+s /home/user2/.bash And yes now user1 ...


0

I would use chown <new username> with all files recuslive and then su <new username> mv the files.



Top 50 recent answers are included