SFTP interface not working over sshfs on OS X

[josipl]

Using SFTP interface on OS X (10.5.8) raises following exception:

exceptions.TypeError: ('Could not adapt', <allmydata.frontends.sftpd.SFTPUser instance at 0x27e34e0>, <InterfaceClass twisted.conch.interfaces.ISession>)

The problem occurs with ​ExpanDrive and ​Transmit. Connecting with sshfs command worked, but only if it was issued as root - in that case other users can't access the mounted disk.

You can see the ​full log for sftp, sshfs, and Transmit.

[davidsarah]

I've made SFTPUser implement ISession (the interface that the logs showed it as failing to be adapted to), which should either fix this problem or allow it to get slightly further. Please 'darcs pull' on the ticket1037 branch and try again.

[josipl]

Replying to davidsarah:

I've made SFTPUser implement ISession (the interface that the logs showed it as failing to be adapted to), which should either fix this problem or allow it to get slightly further. Please 'darcs pull' on the ticket1037 branch and try again.

source:src/allmydata/frontents/sftpd.py was missing from allmydata.util import log and self on line 1247.

Unfortunately it didn't fix the problem, the only exception it now reports is exceptions.NotImplementedError.

Only new thing I noticed in ​log is executing command "df -P -k /".

I've noticed some weird behaviour too: Finder manages to create .Trashes directory and .DS_Store file on the server, but dragging a new file to the disk creates an empty file on the server. Now, even weirder thing is that dragging files into Transmit (for which I suspect is using sshfs internally) uploads the files correctly but it can't list directories, just like Finder.

[davidsarah]

Replying to josipl:

Only new thing I noticed in ​log is executing command "df -P -k /".

The ticket1037 branch now attempts to fake the output of this command (but I've had to make some guesses about how to implement ​execCommand since the Twisted documentation is very sparse). Please pull and try again.

I've noticed some weird behaviour too: Finder manages to create .Trashes directory and .DS_Store file on the server, but dragging a new file to the disk creates an empty file on the server.

This is an independent problem -- probably the same one mentioned in ticket:1037#comment:5. The file is empty because the handle is opened with FXF_EXCL (equivalent to POSIX O_EXCL) in the flags, which means that we have to create a zero-length file first. Then the 'close' hangs and the zero-length file is left in place.

Now, even weirder thing is that dragging files into Transmit (for which I suspect is using sshfs internally) uploads the files correctly but it can't list directories, just like Finder.

Perhaps it only depends on the 'df' command when showing a directory listing (which would make sense if the listing shows the free space on the disk).

[josipl]

The ticket1037 branch now attempts to fake the output of this command (but I've had to make some guesses about how to implement ​execCommand since the Twisted documentation is very sparse). Please pull and try again.

Unfortunately, the problem is still there. Sometimes, a file or two get shown in Finder but that's it. From the ​log I'd say that the connection is dropped too early. Now this exception is being raised all the time:

exceptions.AttributeError: 'NoneType' object has no attribute 'write'

[zooko]

David-Sarah think that this issue has been fixed in their branch. Here are their instructions for testing the branch:

​http://tahoe-lafs.org/pipermail/tahoe-dev/2010-May/004339.html

[josipl]

Replying to zooko:

David-Sarah think that this issue has been fixed in their branch. Here are their instructions for testing the branch:

​http://tahoe-lafs.org/pipermail/tahoe-dev/2010-May/004339.html

Unfortunately not even the latest patches fixed the problem (there was a missing write method on FakeTransport). According to ​log no exceptions are raised, yet nothing shows up in Finder.

[davidsarah]

Please darcs revert then darcs pull again. The problem appears to have been due to sshfs refusing to operate on files and directories that are not world-readable (or world-writeable for writing). sshfs arguably shouldn't have been doing that, but in any case, the current branch now reports the permissions needed for it to work.

(Thanks to josipl and francois for help with debugging this.)