Cannot transfer files with SSH Clients (Cyberduck, FileZilla)

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?

Clyde

@morpie That's normal for the files in the directory /boot. They are system files to be edited only by root or by pi using the command sudo that grants temporary administrative rights. The rwxr-xr-x is grouped in three blocks of rwx (r=read, w=write, x=execute) for the owning user (u), the owners user group (g), and all others (o). So here, u can r+w+x, whereas g and o can only r and x. Did I make myself clear? :)

So, your permissions and ownerships are correct (in this case). To edit them from afar, you could check if your SSH applications can somehow use sudo to escalate the rights of pi to administrative level when editing the files.

By the way, please also show the command you used for the output in the future, and put both in a code block (see the Markdown help page how to do that). Example:

$ ls -l /boot/
total 22126
-rwxr-xr-x 1 root root   23219 Sep 13 10:04 bcm2708-rpi-0-w.dtb
-rwxr-xr-x 1 root root   22716 Sep 13 10:04 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root   22975 Sep 13 10:04 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root   22493 Sep 13 10:04 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root   24019 Sep 13 10:04 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root   25215 Sep 13 10:04 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root   25478 Sep 13 10:04 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root   23991 Sep 13 10:04 bcm2710-rpi-cm3.dtb

The $ indicates the command prompt and is often used to indicate that this is the executed command and not part of the output.

morpie

@clyde

Thank you, and sorry for the disturbance.

I am not sure then why it's not working as it was. This was never an issue, and I am using the same build as before, as well as tried the retropie build on the Retropie official site. This is frustrating to say the least as I never had issues editing config files. Without the ability it makes Retropie kind of lame... so I am gonna have to try something. Ugh.

Clyde

@morpie Well, you could make the files in question writable for others with this command:

sudo chmod o+w /path/to/filename

(o+w means "give (o)thers (w)rite permissions". o-w would take them away.)

This should cause no problems apart from making the system a little less secure, but I don't have enough knowledge of Retropie's internals to say that for sure.

A better way would be to figure out how to edit files remotely with sudo rights escalation.

morpie

I just cant understand what has changed between builds that I am not able to do this. I have to think its something with my computer expecting the Pi to be different. I wonder if changing the IP of the Pi would allow me to try it "fresh" so to speak.

Clyde

@morpie The IP shouldn't change the access level on the Pi, but who knows how your applications do their thing exactly. A program accessing an ssh connection shouldn't behave differently than a direct ssh login in that regard, edit: because it just logs into the Pi like ssh does itself. And in your case, a user/program logged in as pi has to elevate the rights to root level to modify the files you listed, so if Cyberduck and FileZilla don't do that, it's normal that they can't write to those files.

Maybe your old Retropie installation had custom permissions you don't remember anymore? Or you only modified other config files that belong to pi like those in /opt/retropie/configs/? These two seem to me to be the best explanations at the moment if it worked then but doesn't now without any other changes.

Which Retropie version was the old installation? Though I doubt that the permissions of or within /boot were different in previous versions, I don't have that insider knowledge.