Cannot transfer files with SSH Clients (Cyberduck, FileZilla)

mitu

@morpie said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

... or does this sound like misplaced thinking and its something totally different? Anyone had similar issues?

What user are you using to connect to the PI and where are trying to write files ? Just as in Windows, certain folders might not be writable for the user you are using to connect (most likely the pi user). You can copy them into the user's home folder (/home/pi), then move them into place from the command line using sudo cp <file_source> <file_dest>.

morpie

I was able to write to it before just fine. This is just a new install on a different card.

As for the ssh via command line, I use Cyberduck because its drag and drop, and also because when I use command line Mac adds duplicates and I dont want to deal with that.

It worked before fine, just wondering whats different.

treaves

Write permission on the directory. As a brute force approach, you can ssh in and the chmod -R 777 *

mitu

@treaves said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

. As a brute force approach, you can ssh in and the chmod -R 777 *

Please don't do that.

mitu

@morpie Maybe you were using the root account to log in on the old installation, while now you're logging in as user pi.

morpie

I have always used Pi as the sign in name... it would read as pi@(ipaddress). I am doing everying the same as I used to. Im stumped.

Clyde

@morpie Does /var/log/auth.log contain anything informative? (I'm not at home, so I can't check if Retropie even fills this log.)

HurricaneFan

If your pi uses the same ip as your old build, its possible your known_hosts file on the mac has the wrong key saved for the pi.

/users/<username>/.ssh/Known_Hosts

Nevermind, you are saying you can ssh through terminal. This would fail before your successful terminal session.

What build of retropie are you using?

Clyde

@clyde said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

@morpie Does /var/log/auth.log contain anything informative? (I'm not at home, so I can't check if Retropie even fills this log.)

I just checked – yep, it does.

morpie

I have looked at the auth.log file, and see that it has history from before I ever installed the build on this card. I am not sure if that is important, but presume there is.

When I try to see the known hosts, I typed the command with the appropriate information, and permission was denied. I am the only user and have admin so I am not sure why it would do that. Perhaps that's not what I was supposed to do with the known hosts search?

Clyde

@morpie said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

I have looked at the auth.log file, and see that it has history from before I ever installed the build on this card. I am not sure if that is important, but presume there is.

You should look at its end right after you tried to access the Pi and failed. One way to look at it in real time and see any new entries as they happen is this command in the Retropie console:

tail -f /var/log/auth.log

tail displays the last 10 lines of a file (you can change that number by the -n option, e.g. tail -n 20 …). The -f stands for "follow" and will display any new lines in the file immediately. Like most ongoing console commands, you end it by pressing ctrl+c. Without -f it just exits after 10 or -n x lines.

You could show us the output generated on failed login attempts, if it doesn't tell you anything. But be sure to delete any personal information it may contain before posting it in a public forum.

morpie

It logs in fine. When I try to save a file or edit one on the card, I am met with the following error:

"Permission denied. Please contact your web hosting service provider for assistance."

This is the output from auth.log on my pi. I see lots of mention of user Root. I have never used or needed to use that. Always logged in as pi@(ipaddress). I installed it to an SD card from download on the 7th of October.

Aug 23 19:12:20 retropie systemd: pam_unix(systemd-user:session): session opened for user pi by (uid=0)
Aug 23 19:13:25 retropie sudo: pi : TTY=tty1 ; PWD=/home/pi ; USER=root ; COMMAND=/home/pi/RetroPie-Setup/retropie_packages.sh retropiemenu launch /home/pi/RetroPie/retropiemenu/wifi.rp
Aug 23 19:13:25 retropie sudo: pam_unix(sudo:session): session opened for user root by pi(uid=0)
Aug 23 19:13:46 retropie sshd[583]: Received SIGHUP; restarting.
Aug 23 19:13:46 retropie sshd[583]: Server listening on 0.0.0.0 port 22.
Aug 23 19:13:46 retropie sshd[583]: Server listening on :: port 22.
Aug 23 19:13:57 retropie sudo: pam_unix(sudo:session): session closed for user root
Oct 7 12:40:24 retropie sudo: pi : TTY=tty1 ; PWD=/home/pi ; USER=root ; COMMAND=/home/pi/RetroPie-Setup/retropie_packages.sh retropiemenu launch /home/pi/

mitu

@morpie root logins are from running the setup script, which is normal. Where are you trying to write/edit files - which folder ? Does the pi user has write permissions on that folder ?

morpie

It does have write permissions and the other files should have the write permissions as I am the owner, no?

I am trying to edit files like boot/config.txt as per usual and they wont let me save or edit the files. This has never been an issue before, and not sure what I am doing wrong or different from previous builds.

mitu

@morpie said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

I am trying to edit files like boot/config.txt as per usual and they wont let me save or edit the files

Is this the only file that's not editable or just an example ? Can you edit the file from the terminal with nano /boot/config.txt as the user pi ?

morpie

Can add a rom to the Arcade Folder... that is good.

I still cannot edit config and command files as it says permission denied, even using the terminal on the pi.

mitu

@morpie said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

even using the terminal on the pi.

That means you don't have permissions for writing the file. There's no problem with SSH. If you want to edit the file, prefix the editor command with sudo. So instead of nano <path/to/file> to edit, run sudo nano <path/to/file>.

morpie

Thanks will try now. How do I change the permissions? This never was an issue before, how did it change?

Clyde

@morpie Please give us the output of this command for the directory you can't edit files in:

ls -l /path/to/directory
# example
ls -l /opt/retropie/configs/all/

The line with the file in question would be enough to tell if its ownership and/or permissions are wrong.

@morpie said in Cannot transfer files with SSH Clients (Cyberduck, FileZilla):

Thanks will try now. How do I change the permissions?

In the console with the command chmod. But before you do that, we should determine if and which files have wrong permissions to know if and how to correct them. That's why I don't elaborate on chmod yet. (edit: If the ownership is wrong, the command is chown.)

morpie

Clyde, the config files in boot are not editable, so this is the output:

total 20224
-rwxr-xr-x 1 root root 13221 Jun 22 2016 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 13484 Jun 22 2016 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 13257 Jun 22 2016 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 14567 Jun 22 2016 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 15237 Jun 22 2016 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 17932 Jun 22 2016 bootcode.bin
-rwxr-xr-x 1 root root 180 Aug 22 2016 cmdline.txt
-rwxr-xr-x 1 root root 1719 Aug 22 2016 config.txt
-rwxr-xr-x 1 root root 18693 Jun 22 2016 COPYING.linux
-rwxr-xr-x 1 root root 2504 Jun 22 2016 fixup_cd.dat
-rwxr-xr-x 1 root root 6482 Jun 22 2016 fixup.dat
-rwxr-xr-x 1 root root 9717 Jun 22 2016 fixup_db.dat
-rwxr-xr-x 1 root root 9717 Jun 22 2016 fixup_x.dat
-rwxr-xr-x 1 root root 145 May 27 2016 issue.txt
-rwxr-xr-x 1 root root 4224232 Jun 22 2016 kernel7.img
-rwxr-xr-x 1 root root 4123112 Jun 22 2016 kernel.img
-rwxr-xr-x 1 root root 1494 Jun 22 2016 LICENCE.broadcom
-rwxr-xr-x 1 root root 18974 May 27 2016 LICENSE.oracle
drwxr-xr-x 2 root root 8192 Aug 19 2016 overlays
-rwxr-xr-x 1 root root 617432 Jun 22 2016 start_cd.elf
-rwxr-xr-x 1 root root 4926264 Jun 22 2016 start_db.elf
-rwxr-xr-x 1 root root 2746552 Jun 22 2016 start.elf
-rwxr-xr-x 1 root root 3877720 Jun 22 2016 start_x.elf
drwxr-xr-x 2 root root 2048 Aug 23 2016 System Volume Information

Says Root... is this the ownership issue I am looking for? Or is that same as before?