Summary: | sftp now failing to make connection - takes multiple tries | ||
---|---|---|---|
Product: | [Unmaintained] kio | Reporter: | David Rankin <drankinatty> |
Component: | sftp | Assignee: | Oswald Buddenhagen <ossi> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | adawit, alf, asn, finex, jo, mrgrim, wstephenson |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
tar file containing 3 screenshots discussed in original report
screenshot showing error dialog on 1st failed sftp connect attempt error in qwenview showing failed connection kate sftp error on SAVE Just the dialog after successful sftp connection (showing very few entries to be transferred) kio_sftp session log created by kdedebug kdebug log sshd log |
Description
David Rankin
2009-11-13 02:18:08 UTC
Created attachment 38293 [details]
tar file containing 3 screenshots discussed in original report
Please, would you like to attach the three screenshot separately? Many thanks. Dawit, please take a look at bug #213463 too. *** Bug 213463 has been marked as a duplicate of this bug. *** (In reply to comment #4) > *** Bug 213463 has been marked as a duplicate of this bug. *** Guys, just checking in. This bug is still killing me in: Kate Version 3.3.4 Using KDE 4.3.4 (KDE 4.3.4) This is on the new openSuSE 11.2 (as well as 11.0 and Arch Linux) I am running kate and I need to edit 4 short scripts on another box on my lan. sftp fails to connect the first time. Then I have to hit F5 multiple times just like when fish was FU. But the most dangerous part of all -- now saving fails for the same reason and I have to hit save 4-6 times before it will save. (You get the error box each time it doesn't, but switching back and forth between mail, kate, firefox, etc..., I could see doing a quick ctrl+s and alt+tab and missing the dialog) Do you still want me to post the separated pics? I guess I'll do it anyway -- can't hurt. (crap, I see the point, I had to download the screenshots again to remember which ones they were...) I'll post them separately shortly. Created attachment 38759 [details]
screenshot showing error dialog on 1st failed sftp connect attempt
Created attachment 38760 [details]
error in qwenview showing failed connection
Created attachment 38761 [details]
kate sftp error on SAVE
The document had been open for about 5 minutes, then when you try to save, sftp fails and you have to repeatedly save until it works. It usually take 2-4 retries before it will save. Up until this bug appeared several weeks ago, sftp was bullet-proof and worked every time.
Created attachment 38762 [details]
Just the dialog after successful sftp connection (showing very few entries to be transferred)
Well, kio_sftp in KDE 4.3 hasn't changed since 5 month. The bug is somewhere else. This could be a KProcess bug. Oswald, I assumed this is a KProcess bug, but KProcess didn't change in the last 5 month and kio_sftp too. Do you have any idea which could be the cause of this problem now? I've talked to Oswald. As the code we use here didn't change since quite some time we assume that QProcess is broken in newer Qt versions. I have no time at the moment, could someone test it with older Qt versions? I just encountered this bug again, however with different sftp errors. What I did was opening a dolphin window and opened a sftp://remote.server.com/path/to/remote/directory Then I dragged a file from the remote dir over an open kate, which then opened the file. I edited the file and saved, everything ok. I kept on editing and saved, now I got a kate error message: Could not write to /path/to/file/on/remote/server/filename.part Tried again, same error. Did something else, save again: worked flawless. Edit again, same error message. Repeat above steps... This should really be fixed, as a kio slave which works sometimes is pretty much useless... openSUSE 11.2 x86_64 KDE 4.3.4 QT 4.5.3 I'm not at home atm. I will look at it next weekend or Monday. In the meantime could you please provide more info? kdebugdialog --fullmode Debug area: 7120 kio_sftp Information: choose output to file and define a file. Call 'kdeinit4' to reload the slave system. Reproduce the bug and post the log file. Thanks for your time and help! Created attachment 39661 [details]
kio_sftp session log created by kdedebug
THX this kdebugdialog thing comes in pretty handy. My comments to the log file: - the "COULD NOT WRITE ... *.part" permissions= -1 seem to be the interesting ones. I guess -1 means "no info"? However, this problem is not caused by file permission problems, I double checked this, and it works after some time w/o any filesystem modification. - I experienced some read remote file errors, see log for entries like kio_sftp(14368) sftpProtocol::get: bytesread= "11254" kio_sftp(14368) sftpProtocol::get: bytesread= "0" In this case, kate is stalled and it is necessary to close the progress popup and the current file view, then reload. - The "sftpProtocol::put ... mode= "438"" seems to say that the temp. files are always created with (octal) file permission 0666 (rw for everyone), this is not a good idea, IMHO 0600 would suffice. - AFAICS kio_sftp work well for the first put operation. Following put operations won't work until sftpProtocol::closeConnection: closeConnection() happends. After that, I can save 1 file, all following seve attempts return the known error. What surprises me is that the bug is really easy to reproduce for me (implying that a lot of ppl should experience the same), either very few ppl use kio_sftp (which would surprise me) or the bug depends on external issues like sshd configuration. The sshd is configured to use ssh2 protocol only, and key based authentication is configured (I don't know wether kde4 uses this). I am not using KWallet. I've tried to reproduce it but everything works just fine here. I guess I have already fixed it with bug #220628. How can that be? It looks like 220628 is against trunk and the new rewritten sftp ioslave? openSUSE has backported the new kio_sftp to KDE 4.3.x. I have to create a patch for them. I suppose that's what I get for abandoning opensuse... The problem still exists in KDE 4.4.3 (openSUSE 11.2), leaving kio_sftp unusable. I need more information to be able to understand and reproduce the bug. What are you trying to do. Which version of libssh do you use and which ssh server and version are you running? Could you provide logfiles from server and client? It is pretty much the same situation as I described in 2010-01-07 I am editing a file with kate opened via sftp. Whenever I save the file a message apears "Could not change permissions for $pathtoremotefile/$filename" But the changes are applied to the remote file. However, when applying further changes withing the next ~5min an error is displayed "Could not write to $pathtoremotefile/$filename.part." The same action works perfectly well when issued from a KDE3 GUI, the file permissions are ok, ssh works flawless. There are no log entries in the ssh log (with LogLevel Info), this isn't a server/client problem but an application level bug. Maybe this is related to the bug: I tried to replace an existing file via kio_sftp on a remote server. Apparently the ctime is not proper read, the dialog "File already exists" says "01.01.1970" for creation date on both files which is wrong. The screenshots from comment #6 and #7 have absolutely nothing to do with this. The questions is still which version of libssh are you using. Which ssh server are you connecting to. Do you have a special setup there. Is AppArmor or SELinux protecting the machine. Do you connect as user or as root? Can you provide log files? I don't know if it is related, but since I'm using KDE4 I'm having some troubles when I open a lot of files using ftp/sftp with kate (I've already reported it, I don't remember the exact bug number). For example I drag and drop 10 files from konqui/dolphin to kate: some files are opened, some other not. The error message is "Impossible to connect to localhost" and there are "empty name" entries on the kate sidebar. I can click on them, press F5 multilpe times until the file is loaded. There is nothing relevant on the local logs and on the server log. Created attachment 43605 [details]
kdebug log
The described problems are related to the remote sshd version. On the particular server openssh 2.2.9pl2 is used. Concurrent versions of sshd are nor affected (verified by connection to servers running 5.1.pl1 and 5.2.pl1). It looks like that the server is silently closing the connection and then we try to talk to it again and the server doesn't know the opened file anymore. This is an openssh bug or a libssh problem. Maybe it is possible to work around the problem, but we would need to investigate this further. This means we need debuglog of the server and the client to find out what they are doing before the and after the error. Is this a Linux machine running openssh 2.2.9pl2? Could you create a bug at http://dev.libssh.org/ ? Created attachment 43639 [details]
sshd log
LogLevel DEBUG
The folowing actions were logged:
1) Connecting via kio_sftp to the server
2) Opening a remote file in kate
3) Saving the file (Msg: Could not change permissions ...), file saved
4) Saving the file again (Msg: Could not write to ...), file _not_ saved
I doubt this is a server side problem, since the only sftp client which has problems is kio_sftp from kde4. All other ssh clients (including cmdline ssh/sftp/scp on Linux/FreeBSD, winscp, putty, kio_sftp from kde3) do work without any problem. Yes, the machine is running Linux. We have identified the problem. sftp doesn't honor the packet limit. This is a blocker for 0.4.3 now. We will fix it and then release a new version. This bug is handled upstream now. http://dev.libssh.org/ticket/81 This bug has been hijacked. The recent discussion is not related to the original problem at all. This bug was originally opened regarding a pre libssh kio_sftp problem in kde 4.3.x and older. How should we handle this? Should a new bug regarding the new issue be opened and the recent discussion copied, or should a new bug for the old issue be opened? |