Closed boyska closed 11 years ago
damn, now I kind of understand why truecrypt ships their own cryptsetup :/
check made with Tomb 1.2 (current stable) also from arch doesn't mount a tomb over sshfs. file on file tomb gives:
16:48
instead cryptsetup isLuks gives a 1 and the error is:
16:53
which to us right now means the loopback device limit is reached by mounting an sshfs.
how stoopid from a distro to keep such a limit so low...
o0 that's odd. This would also mean that mounting two tombs will make losetup reach the limit? and, is there a way to increase the number of loopback devices with a command? (btw, is sshfs a loopback device ? I did not think so)
Il giorno Wed, 18 Jan 2012 03:52:57 -0800 BoySka reply@reply.github.com ha scritto:
That's a nasty issue. Here's the scenario. A tomb is on a remote server. The key is on our usb pen. We mount the remote server filesystem using sshfs. tomb has troubles when opening it.
Some notes:
file $tombname
detects it correctly- deleting the check does not solve the problem: cryptsetup fails
- copying the tomb on local filesystem make it work
- lot of ssh servers tried
This bug does NOT happen on archlinux. So, I think the problem is on a old version of cryptsetup. on archlinux I have cryptsetup 1.4.1; every ubuntu version has cryptsetup 1.1 (so upgrading to natty narwal won't solve); debian stable has 1.1, testing and unstable has 1.3
This is not correct, I have archlinux too so the same version of cryptsetup.
I think that is a permissions issue because if I mount as root with sshfs there are no problems whit the cryptsetup check but if I try as normal user it fails.
Can anyone check this on as much platform/combination to confirm/disprove my hypothesis?
It would be especially good to know WHICH version of cryptsetup is required to do this and if there is a workaround
How do you mount your remote fs with sshfs?
[ nignux ----------------------------------------- nignux@freaknet.org ] [ GPG-ID:: 28B4358A ------------------------------- http://pgp.mit.edu ] [ GPG-Fingerprint:: 24E1 483B 7BE1 0853 87DA C1E4 3915 F8AC 28B4 358A ]
thanks for your testing nignux. Indeed, I have double-checked and you're right.
doing sudo sshfs
works, doing sshfs
as user does not work.
The problem, I suppose, is that root cannot access an sshfs mounting.
$ sshfs blah@host /mount/point
$ sudo bash
# cd /mount/point
bash: cd: point: Permesso negato
so it cannot access the tomb.
So, it seems it's NOT a cryptsetup issue, but an sshfs issue; maybe there is an option which enables root access to sshfs.
Il giorno Sun, 22 Jan 2012 04:53:17 -0800 BoySka reply@reply.github.com ha scritto:
thanks for your testing nignux. Indeed, I have double-checked and you're right. doing
sudo sshfs
works, doingsshfs
as user does not work. The problem, I suppose, is that root cannot access an sshfs mounting.$ sshfs blah@host /mount/point $ sudo bash # cd /mount/point bash: cd: point: Permesso negato
so it cannot access the tomb.
So, it seems it's NOT a cryptsetup issue, but an sshfs issue; maybe there is an option which enables root access to sshfs.
Yes and IT WORKS.
sshfs -o allow_root user@remote.host:/ /local/mountpoint/
[ nignux ----------------------------------------- nignux@freaknet.org ] [ GPG-ID:: 28B4358A ------------------------------- http://pgp.mit.edu ] [ GPG-Fingerprint:: 24E1 483B 7BE1 0853 87DA C1E4 3915 F8AC 28B4 358A ]
if this is confirmed as a solution (I think so), it can be closed documenting it (it's not strictly tomb-related, but it is a common setup, so we should document it, I think)
yes should be documented, thanks guys for finding it, that was itchy scratchy
who wants to be the first to write it? :) https://github.com/dyne/Tomb/wiki/TombSshfs
closing the issue, as it was solved a year ago.
That's a strange issue. Here's the scenario. A tomb is on a remote server. The key is on our usb pen. We mount the remote server filesystem using sshfs. tomb has troubles when opening it.
Some notes:
file $tombname
detects it correctlyThis bug does NOT happen on archlinux. So, I think the problem is on a old version of cryptsetup. on archlinux I have cryptsetup 1.4.1; every ubuntu version has cryptsetup 1.1 (so upgrading to natty narwal won't solve); debian stable has 1.1, testing and unstable has 1.3
Can anyone check this on as much platform/combination to confirm/disprove my hypothesis?
It would be especially good to know WHICH version of cryptsetup is required to do this and if there is a workaround
EDIT: it happens on archlinux, too. It seems a permission problem, see below.