make command does not work when using an sshfs mounted volume

[ultima-originem]

I want to backup a Raspberry Pi running Jessie from the RPI to a NAS, mounted as an sshfs mounted volume.

I used the following command to mount the volume:

... sudo sshfs admin@diskstation:/RPI/rpi-full-backups /mnt/nas -o IdentityFile=~/.ssh/id_rsa,idmap=user,reconnect,uid=1000,gid=1000,allow_other ...

This works fine; I can access the volume without providing a password. I then installed the dcs-tools - following the provided instructions - on the NAS from the RPI. When I run the command I get the following output:

pi@araminta:/mnt/nas $ make set-local-session
make: Makefile: No such file or directory
make: *** No rule to make target 'Makefile'.  Stop.

It looks like the symbolic link to the sshfs mounted volume does not work and therefore the Makefile is not found.

Any suggestions?

[ceremcem]

OK, here we go:

First of all, you loose most benefits of rsync when you mount remote filesystem here and perform a backup, because rsync determines all changes locally, which causes all IO operations take place over the wire. I suggest using backup tool remotely, in NAS.

But anyway, your setup should work as you expected. Would you try creating hard/soft links like so:

cd /mnt/nas
touch test.txt
ln -s test.txt 111.txt
cp -al test.txt 222.txt
echo "heyy" > 222.txt
cat test.txt

[ultima-originem]

Two answers: first the output of your commands:

pi@araminta:~/scripts $ cd /mnt/nas pi@araminta:/mnt/nas $ touch test.txt pi@araminta:/mnt/nas $ ln -s test.txt 111.txt pi@araminta:/mnt/nas $ cp -al test.txt 222.txt pi@araminta:/mnt/nas $ echo "heyy" > 222.txt pi@araminta:/mnt/nas $ cat test.txt heyy

Secondly: I want to run the backup from the RPI as it's linux environment is more standard compared to the NAS. Please correct me if this is either impossible or undesirable. I'n now accessing the backup volume via SSHFS but perhaps ther's another way.

[ceremcem]

You are right about the standart Linux environment comparison, and I would prefer as you did in your circumstances.

OK, let's move on. Did you properly setup aktos-dcs-tools, since it doesn't seem to be? Can you post the following commands output:

cd /mnt/nas
git clone https://github.com/aktos-io/aktos-dcs-tools
./aktos-dcs-tools/configure 
ls -la
make set-local-session
ls -la 
make init 
ls -la
make backup-root 

[ultima-originem]

Done; I stopped at a certain point due to errors:

pi@araminta:/mnt/nas $ git clone https://github.com/aktos-io/aktos-dcs-tools
Cloning into 'aktos-dcs-tools'...
remote: Counting objects: 177, done.
remote: Total 177 (delta 0), reused 0 (delta 0), pack-reused 177
Receiving objects: 100% (177/177), 24.98 KiB | 0 bytes/s, done.
Resolving deltas: 100% (113/113), done.
Checking connectivity... done.
pi@araminta:/mnt/nas $ ./aktos-dcs-tools/configure
pi@araminta:/mnt/nas $ ls -la
ls: cannot read symbolic link Makefile: No such file or directory
ls: cannot read symbolic link 111.txt: No such file or directory
total 24
drwxrwxrwx 1 pi   pi   4096 Oct 23 19:39 .
drwxr-xr-x 3 root root 4096 Oct 20 14:05 ..
lrwxrwxrwx 1 pi   pi      8 Oct 23 18:54 111.txt
-rw-rw-rw- 1 pi   pi      5 Oct 23 18:54 222.txt
drwxrwxrwx 1 pi   pi   4096 Oct 23 19:39 aktos-dcs-tools
lrwxrwxrwx 1 pi   pi     33 Oct 23 19:39 Makefile
pi@araminta:/mnt/nas $ make set-local-session
make: Makefile: No such file or directory
make: *** No rule to make target 'Makefile'.  Stop.

[ceremcem]

I can't get it, since sshfs was seem to be comfortable with links, but now I'm sure that this error is absolutely related with hard links.

Would you try mounting remote filesystem via sshfs with -o transform_symlinks option?

Edit

Which sshfs version are you using?

[ultima-originem]

I tried it:

sudo sshfs admin@diskstation:/RPI/rpi-full-backups /mnt/nas -o IdentityFile=~/.ssh/id_rsa,idmap=user,reconnect,uid=1000,gid=1000,allow_other,transform_symlinks

No difference:

pi@araminta:/mnt/nas $ ls -als
ls: cannot read symbolic link Makefile: No such file or directory
ls: cannot read symbolic link 111.txt: No such file or directory
total 24
4 drwxrwxrwx 1 pi   pi   4096 Oct 23 20:30 .
4 drwxr-xr-x 3 root root 4096 Oct 20 14:05 ..
4 lrwxrwxrwx 1 pi   pi      8 Oct 23 18:54 111.txt
4 -rw-rw-rw- 1 pi   pi      5 Oct 23 18:54 222.txt
4 drwxrwxrwx 1 pi   pi   4096 Oct 23 20:30 aktos-dcs-tools
4 lrwxrwxrwx 1 pi   pi     21 Oct 23 20:30 Makefile

You can already see from the output of ls -als that the link is not recognized.

[ceremcem]

...and the sshfs version you are using?

[ultima-originem]

pi@araminta:/mnt/nas $ sshfs -V SSHFS version 2.5 FUSE library version: 2.9.3 fusermount version: 2.9.3 using FUSE kernel interface version 7.19

pi@araminta:/mnt/nas $ uname -a Linux araminta 4.1.19+ #858 Tue Mar 15 15:52:03 GMT 2016 armv6l GNU/Linux

[ultima-originem]

I solved the problem. The original problem is caused by SSHFS not supporting hardlinks although available documentation says it does. I moved the mount from SSHFS to NFS and hardlinks are no longer a problem.

[ceremcem]

A-ha! Congratulations! :+1:

Well, I will keep this issue open in order to add such a check. Maybe a make test would suffice?

[ultima-originem]

That would be an excellent idea.