0

I use image-backup to backup my Rpi. I backup directly on an FTP server and I do so via sshfs.

This is how I connect in my /etc/fstab:

MYUSERNAME@MYSERVER:/home/myuser/rpi_backup /mnt/MYSERVER fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,identityfile=/home/pi/.ssh/id_rsa,allow_other,default_permissions 0 0

Here my /etc/fuse.conf

user_allow_other

I get the error that I dont have permissions:

rsync: [generator] symlink "/tmp/img-backup-mnt/boot/cmdline.txt" -> "firmware/cmdline.txt" failed: Operation not permitted (1)

I have tried also the following commands but this didn't fix it:

sudo groupadd fuse sudo usermod -a -G fuse pi

Someone has an idea of what else I could try to fix this?

Many thanks!

EDIT:

So in the end it isn't SSHFS at all.

When using sudo image-backup and then enter the destination /mnt/test.img I get the same error.

I understand that a custom program is difficult to troubleshoot and to look whats wrong but what rsync commands can I test to reproduce or narrow down the errors? Thanks.

Improve this question
3
  • unix.stackexchange.com/a/701487/108618 Commented Dec 26, 2023 at 22:33
  • Why sudo echo foo >>file "fails" is that the >>file is handled by the parent shell, running as $USER, before sudo is executed. Commented Dec 26, 2023 at 23:22
  • 1
    I removed the part with sudo echo in my question. This works now for some reason. Commented Dec 26, 2023 at 23:44

1 Answer 1

Reset to default
0

I removed the part with sudo echo in my question. This works now for some reason.

@waltinator already explained it in his comment, here is the long version:

A command line is interpreted by the shell in several distinct steps. One of these steps - a rather early one - is to process redirections. This is why a command like:

sudo -s /some/command > /some/where

is NOT interpreted as "pass /some/command > /some/where to sudo -s" but the redirection is processed first and the output of sudo -s /some/command is redirected to /some/where. Only then sudo is called and passed the option -s and the command line argument /some/command.

This means, that a process running under your user ID and with your privileges writes to the redirection target and presumably your privileges don't encompass writing there.

The solution is to create a process which is indeed able to write there:

sudo -s /some/command | sudo -s tee [-a] /some/where > /dev/null

You see, both the "/some/command" and the "tee" which does the writing run with elevated privileges.

Notice that you need to use the "-a" flag if you want to append the file, leave it out for overwriting the file. Also notice that you need to redirect the output of tee to /dev/null if you don't want to have what is written to the file clutter your screen.

Improve this answer
1
  • Many thanks for your answer. I have removed the « echo » part of my question as I understood my wrongdoing. Having said this, my problem with sshfs is still unsolved. Commented Jan 3, 2024 at 0:22

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.