Cannot transfer files with SSH Clients (Cyberduck, FileZilla)

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.

Clyde

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

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.

P.S.: And you can minimize even that by setting o+w only briefly for the modification and then setting it back to o-w.

morpie

I rebuilt my image using the Attract Mode build and updated everything following Floob's advice. I redid it last night from scratch - and editing the config.tx and cmdline.txt files were successful. I presume I must have missed something or other that caused an issue with the folders. I still need to try Cyberduck, but am now optimistic about being able to SSH.

Hopefully it was just an issue with my install. Thank you for all of the help. Will keep you posted.