SUMMARY In an SFTP location, defined either by adding an entry to Places or by adding a new network, attempts to follow a symbolic link fail with the message, "Could not read file sftp://..." This happens with links that point to locations within the user's home directory as well as locations outside it (IOW, this is not caused by a chroot restriction). This started occurring recently, most likely after an update from the kubuntu-backports repo. If the SFTP location is mounted (using 'mount'), symbolic links can be followed as expected. STEPS TO REPRODUCE 1. Create an SFTP entry in Places, or add it as a new network in Networks. 2. Navigate to the location created in #1 and click on a symbolic link within the location. OBSERVED RESULT Error dialog appears saying, "Could not read file sftp://..." EXPECTED RESULT Access the directory/file that the symbolic link points to. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 18.04 (available in About System) KDE Plasma Version: 5.12.7 KDE Frameworks Version: 5.47.0 Qt Version: 5.9.5 ADDITIONAL INFORMATION
Please provide a step by step guide on how to reproduce this.
(In reply to Harald Sitter from comment #1) > Please provide a step by step guide on how to reproduce this. The following is from my original bug report. Is there any specific info that's missing? === STEPS TO REPRODUCE 1. Create an SFTP entry in Places, or add it as a new network in Networks. 2. Navigate to the location created in #1 and click on a symbolic link within the location. OBSERVED RESULT Error dialog appears saying, "Could not read file sftp://..." EXPECTED RESULT Access the directory/file that the symbolic link points to. ===
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Steps to reproduce bug were provided in the original bug report.
I may have read over the not in "not caused by a chroot restriction" ^^ Anyway, I cannot reproduce this. - does this happen with every server (e.g. can you reproduce this with localhost). if not what version/type of server. does the server have settings different from the defaults? - is the symlink absolute or relative? (attach output of `readlink $wherethelinkis` maybe) - are you sure it's a symlink and not a hardlink? Please get a log of kio by running dolphin with a suitable url, then triggering the bug: > killall kioslave5; killall -9 kiod5; QT_LOGGING_RULES="log_kio_sftp=true" KDE_FORK_SLAVES=1 dolphin --new-window '$SFTPURL' attach the entire generated output to the bug report please.
Created attachment 126913 [details] QT_LOGGING_RULES="log_kio_sftp=true" KDE_FORK_SLAVES=1 dolphin 'sftp://myname@localhost:22/home/myname/' Output of: > killall kioslave5; killall -9 kiod5; QT_LOGGING_RULES="log_kio_sftp=true" KDE_FORK_SLAVES=1 dolphin 'sftp://myname@localhost:22/home/myname/'
(In reply to Harald Sitter from comment #5) > - does this happen with every server (e.g. can you reproduce this with > localhost). if not what version/type of server. does the server have > settings different from the defaults? Happens with multiple servers, including localhost -- see attached file. > - is the symlink absolute or relative? (attach output of `readlink > $wherethelinkis` maybe) > - are you sure it is a symlinks and not a hardlink? Yes, they're symlinks, _not_ hardlinks, and the links are to absolute locations -- they can be accessed when connected via fish. > > Please get a log of kio by running dolphin with a suitable url, then > triggering the bug: > > > killall kioslave5; killall -9 kiod5; QT_LOGGING_RULES="log_kio_sftp=true" KDE_FORK_SLAVES=1 dolphin --new-window '$SFTPURL' > > attach the entire generated output to the bug report please. Done. (Note that "--new-window" is not a valid option for dolphin.)
The --new-window problem is actually because you use an unsupported version of kio-extras. Combined with the fact that I cannot reproduce this on the upcoming 20.04 I'd wager that this was either fixed in kio-extras or the underlying libssh in a newer version. In your version the stat() call on the URL is failing and there's not anything I can see in the current kio-extras code that could cause that. So, I would suggest asking your distribution about newer kio-extras/libssh builds. I'll see about adding some more debugging for the 20.04 release though, the current output isn't terribly useful for your problem.
Git commit 7b4042b956659835359935f9b427d64d2c065d16 by Harald Sitter. Committed on 23/03/2020 at 09:36. Pushed by sitter into branch 'master'. add some extra debug in case stat fails when createUDSEntry fails we'll really want to know what exactly happened in libssh to help figure out what is wrong if something is wrong. M +2 -0 sftp/kio_sftp.cpp https://commits.kde.org/kio-extras/7b4042b956659835359935f9b427d64d2c065d16
Closing until this can be reproduce on the 20.04 release