You are not logged in.
Pages: 1
Topic closed
A week ago kdeconnect was working fine, within the plasma desktop, without any problem between a laptop and my android phone. Using it today, with no change to any configs, and presumably after some updates that may have affected kdeconnect, I now have an issue where, although the phone and laptop are correctly paired via wifi, for kdeconnect, using dolphin to open the phone's filesystem, using the paired phone's icon on the left of the dolphin window, now shows the 'primary' top level directory as it always did, but clicking on 'primary' within dolphin now gives a series of audible 'bong's and a set of popups saying it can't open the files on the phone, and as those popups appear and roll past there is a mention of sshfs. Yet the phone and laptop are correctly connected and paired, and files can be sent fromthe phone to the laptop without any problem using 'send files' initiated from the phone.
Rebooting the phone makes no difference, and re-pairing the two also makes no difference.
Does anyone know if this bug has a work around? I have not found any upstream bug report on this.
Thanks.
Edit: I would delete the phone from the kdeconnect device list to start afresh, but I could not find a way to remove a previously connected device! Does anyone know if there is a way to remove a device from the kdeconnect list of devices, since I now have an unpaired as well as a paired device but both are the same phone!
Last edited by mcloaked (2021-10-06 19:21:30)
Mike C
Offline
There was a change to the configuration protocol with dolphin.
Delete the "remote" phone location (if you saved one) in dolphin. Close dolphin. Next, open kdeconnect on your phone and on the desktop. Verify on both the phone and desktop is active and selected. Restart dolphin. The phone should now appear automatically under the "devices" section. You should now see the directory tree when you click on the device.
If this does not fix it, check the plugin settings on the phone app.
Regarding the duplicate entries, try unpairing everything you can, then reboot the phone.
Last edited by zpg443 (2021-09-27 13:54:27)
Offline
I repeated as you suggested and indeed the phone is listed as paired and connected and in dolphin the phone shows up in the left side panel, clicking it then shows the top directory in the right main panel. But as soon as I click on the top directory in the right main panel in dolphin, it beeps and says the directories within the top directory can't be seen. I did expose the filesystem in the phone kdeconnect app when I established the new connection - but only at the top directory level. What other settings in the phone app need to be checked or changed? Once the file system is exposed I couldn't find a way to go back and check those settings.
Mike C
Offline
If the filesystem is exposed in the phone's kdeconnect app, it is an issue with permissions on the computer.
In dolphin, under properties for the phone device:
Location should read something like /run/user/1000/xxxxxxxx.
Files system should read: fuse.sshfs.
Mounted on something like: /run/user/1000/xxxxxxxx.
Mounted from something like: kdeconnect@192.168.x.xx.
See also
https://wiki.archlinux.org/title/SSHFS
Last edited by zpg443 (2021-09-27 17:05:34)
Offline
Well I am stumped - I started a brand new connection on a different laptop - it sets up fine, I expose the filesystem without any problem, but as soon as I try to use dolphin to see the directories on the phone, it pops up multiple warnings about "Error when accessing filesystem sshfs finished with exit code 1". The firewall was off as an additional factor to make sure no firewall was coming in to play to cause the issue. This looks to me like a bug in a recent update. I wonder if the latest openssh update could be related? openssh (8.7p1-2 -> 8.8p1-1)
Edit: I get a lot of lines of this form in the journal:
Sep 27 18:26:27 ryzen1 systemd[824]: Started Dolphin - File Manager.
Sep 27 18:26:28 ryzen1 systemd[1]: run-user-1000-xxxxxxxxxxxxxxx.mount: Deactivated successfully.
Sep 27 18:26:28 ryzen1 kdeconnectd[1007]: QDBusAbstractAdaptor: Cannot relay signal SftpPlugin::packetReceived(NetworkPacket): Unregistered input type in parameter list: NetworkPacket
Sep 27 18:26:28 ryzen1 systemd[1]: run-user-1000-xxxxxxxxxxxxxxx.mount: Deactivated successfully.
Sep 27 18:26:29 ryzen1 kdeconnectd[1007]: QDBusAbstractAdaptor: Cannot relay signal SftpPlugin::packetReceived(NetworkPacket): Unregistered input type in parameter list: NetworkPacket
Last edited by mcloaked (2021-09-27 18:09:22)
Mike C
Offline
It is apparently a bug. I just upgraded and got the same error. Try downgrading openssh.
Last edited by zpg443 (2021-09-27 19:54:41)
Offline
sshfs has openssh as a dependency - and since openssh has just updated then it is certainly possible that the newly updated openssh package could lead to a bug with sshfs. Yes of course I have the sshfs package installed. Can someone confirm that they have kdeconnect working correctly in fully updated arch linux systems please, or it is that it is only me who has this problem, or have others tested their systems since openssh updated and found the same issue? My systems were working fine last week, but are not working today. The difference is likely in the updated packages between last week and today.
Mike C
Offline
Please see my edited post (#6). You are right.
Offline
Flagged kdeconnect as out of date. openssh (8.7p1-2 -> 8.8p1-1) causes kdeconnect to fail connect. Reproduce by connecting to desktop using current openssh and open filesystem for remote device in dolphin.
Last edited by zpg443 (2021-09-27 20:05:11)
Offline
Thanks for your edited post confirming you are seeing the same bug as me - so hopefully this will get fixed upstream - perhaps sshfs now needs to be upgraded to accommodate some new feature or limitation in openssh or possibly there is a bug in kdeconnect upstream that need to accommodate some change in the way sshfs works with the updated openssh. I have not yet found an upstream report but the new openssh package may need time before other users also update and find the bug - and then report it. I also note that libssh2 is in testing.
Last edited by mcloaked (2021-09-27 20:58:47)
Mike C
Offline
Core openssh
Community sshfs
Extra kdeconnect
No current bugs or flags for sshfs. Let the kdeconnect maintainer flag sshfs if necessary.
Last edited by zpg443 (2021-09-27 20:25:13)
Offline
Flagged kdeconnect as out of date. openssh (8.7p1-2 -> 8.8p1-1) causes kdeconnect to fail connect.
Please do not do that. We have a bug tracker for a reason.
Offline
It is possible that some of the changes listed in the changelog at https://www.openssh.com/releasenotes.html may have an impact on sshfs and kdeconnect - such as the "potentially incompatible changes" that would affect other code which uses the new incompatibilities.
Mike C
Offline
zpg443 wrote:Flagged kdeconnect as out of date. openssh (8.7p1-2 -> 8.8p1-1) causes kdeconnect to fail connect.
Please do not do that. We have a bug tracker for a reason.
Sorry about that. I verified a bug report was already filed upstream (KDE) here: https://bugs.kde.org/show_bug.cgi?id=442967 before flagging it with arch. Apparently I do not understand the out-of-date flag versus filing a bug report.
Offline
I have put in a new upstream report at https://bugs.kde.org/show_bug.cgi?id=443155
Mike C
Offline
Hey guys I just solved the problem. Install the prior version of openssh. I did it and kdeconnect now works.
sudo pacman -U /var/cache/pacman/pkg/openssh-8.7p1-2-x86_64.pkg.tar.zst
The problem is the newest version of openssh and not sshfs. Until they come out with a bugless openssh just go to your /etc/pacman.conf and do IgnorePkg = openssh so that openssh won't update with all the other updates. Do this until a good openssh is updated.
Offline
Well the new ssh works fine for ssh connections. kdeconnect uses sshfs, and it is possible that sshfs may have a bug exposed by the newest version of openssh, on which it depends. So the bug may be in sshfs, or in kdeconnect, or both. Downgrading openssh is a temporary workaround, but you then lose the benefit of the improvements in ssh by so doing.
Also I have tested sshfs with the newest openssh package and it works without issue, such as making a directory mnt as a mount point doing:
$ sshfs remotemachine:/home/mike/Documents/ mnt
then enter ssh password if the ssh agent is not already set up
then you can list the files on the remote machine using:
$ ls mnt
and then unmount it using:
$ fusermount3 -u mnt
So that all works fine, and suggests the bug is in kdeconnect
Last edited by mcloaked (2021-10-01 12:08:19)
Mike C
Offline
I updated to the latest openssh and again the phone folder is locked. When I go back to the previous openssh it opens and I have access to the phone folder. It's still not great because it takes a lot of time to open it but at least it opens. The only function of ssh that I use is the kdeconnect so I don't care about the other functions. I'll just have to wait until all the elements of kdeconnect are upgraded and bugless. Maybe this proves the value of Manjaro to hold back on any updates before they're tested. I'm testing the latest Manjaro KDE and kdeconnect works like a champ. And they held back on updating the latest openssh too.
Offline
If they are indeed doing active testing and actively hold back the package because of that, otherwise you will just get that error in a week and then wait two additional weeks in the event that the package is fixed here.
Offline
This is now fully resolved with sshfs 3.7.2-2 and kdeconnect 21.08.1-2 and kdeconnect now connects to my Android phone, after re-pairing, and the exposed filesystem on the phone is now visible in the kdedesktop in dolphin.
Edit: The fix is only in the arch packages concerned, as a temporary workaround, and has not yet been fixed upstream in the source files. So users of other Linux distributions will not benefit from a working version of kdeconnect until the upstream developers fix the source code both in the sshfs and the kdeconnect packages.
Last edited by mcloaked (2021-10-07 11:02:45)
Mike C
Offline
I was able to update again to the latest openssh when I also updated the latest kdeconnect. Now everything works fine. However Manjaro just repeated the same issue when they just updated the latest openssh without updating the latest kdeconnect. Kdeconnect now hast the same issue as I had previously with Arch. They should have not updated the latest openssh without also updating the latest kdeconnect. Testing it would have proven it. I know they will but that's not the issue. I now don't see any advantage of Manjaro over Arch. My experiment is over. I'm sticking with Arch all the way and no more Manjaro.
Offline
Check the upstream bug report linked in comment #15
Mike C
Offline
Hello, I also had this problem until I installed openssh and sshfs. openssh was up to date so i reinstalled it, than it turned out that sshfs was not installed or it was an older version. after you install openssh and sshfs it will be solved.
Offline
Closing this old solved topic.
Offline
Pages: 1
Topic closed