SUMMARY Every day I access remote servers via FTP. On these servers, there are some soft links to remote drives (usually mounted with NFS). In those years, I couldn't access the content of those linked folders with Dolphin or Krusader. Every time I tried, both file managers were showing the mouse pointer "busy" for a while, and in the end the folder would open without showing any content. Recently, other colleagues using Windows, showed me that they could see the contents of those linked folders with Filezilla or TotalCommander, so I tried Caja on Linux and it shows the contents of those folders!!!! All in all, yet another kio-fuse problem, unfortunately. STEPS TO REPRODUCE 1. Use Dolphin or Krusader to access a FTP server. In the server, must exist a soft-link to a remote NFS folder. 2. Try to open the solf-link tru FTP with any of those file managers OBSERVED RESULT After about a minute, folder is opened but doesn't show any file (shows it like empty) EXPECTED RESULT To show soft-link folder content SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220218 / LEAP 15.3 KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.4-1-default (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz Memory: 15.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2 ADDITIONAL INFORMATION Soft-linked folder is accesible thru: - Caja (in Linux) - FileZilla, TotalCommander (in Windows)
What do you mean by "soft link"? How would a FTP server link to an NFS share?
I am sorry for not being so explicit. On a server, you create a folder called "FolderShared", and share it with an FTP server. Inside that folder, you create a symbolic link (symlink, no matter if it is "soft" or "hard") that we can call "linkedNFSfolder" to a hard disk, with the same permissions as the rest of the folders hanging from the "FolderShared" folder. kiofuse is not able to show content of "linkedNFSfolder".
(In reply to Rafael Linux User from comment #2) > I am sorry for not being so explicit. On a server, you create a folder > called "FolderShared", and share it with an FTP server. Inside that folder, > you create a symbolic link (symlink, no matter if it is "soft" or "hard") > that we can call "linkedNFSfolder" to a hard disk, with the same permissions > as the rest of the folders hanging from the "FolderShared" folder. > kiofuse is not able to show content of "linkedNFSfolder". Where does the symlink point to, a path within the FTP share, or a location on the FTP client? Is it relative or absolute? Can you provide the output of "stat symlink" on the FTP server and inside the kio-fuse mount?
(In reply to Fabian Vogt from comment #3) > Where does the symlink point to, a path within the FTP share, or a location > on the FTP client? Is it relative or absolute? Can you provide the output of > "stat symlink" on the FTP server and inside the kio-fuse mount? Points to a location on FTP share. Dolphin shows it like "opening /nfs/ficheros" and ends showing nothing at ftp://adminweb@XX.XX.XX.XX/var/www/ficheros/ File: agenda -> /nfs/ficheros Size: 20 Blocks: 0 Block E/S: 4096 symlink Devide: fe08h/65032d inode: 260841 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 1001/adminweb) Gid: ( 1001/adminweb)
On traslating text output, I put this: File: agenda -> /nfs/ficheros and must be this: File: files -> /nfs/files
(In reply to Rafael Linux User from comment #4) > (In reply to Fabian Vogt from comment #3) > > > Where does the symlink point to, a path within the FTP share, or a location > > on the FTP client? Is it relative or absolute? Can you provide the output of > > "stat symlink" on the FTP server and inside the kio-fuse mount? > > Points to a location on FTP share. Dolphin shows it like "opening > /nfs/ficheros" and ends showing nothing at > ftp://adminweb@XX.XX.XX.XX/var/www/ficheros/ > > File: agenda -> /nfs/ficheros > Size: 20 Blocks: 0 Block E/S: 4096 symlink > Devide: fe08h/65032d inode: 260841 Links: 1 > Access: (0777/lrwxrwxrwx) Uid: ( 1001/adminweb) Gid: ( 1001/adminweb) So you're using the the ftp:// protocol in dolphin and clicking on the symlink and that doesn't behave as expected? In that case kio-fuse isn't actually involved. I tried it here with sftp and it worked fine. Dolphin doesn't actually navigate to the link target itself, the path resolution is performed on the server. Can you reproduce the issue with SFTP?
I can't test with an SFTP server because our servers are FTP servers managed by other teams. In any case, it's clear to me that to be secure or not has nothing to do with the problem. I'm not an expert on KDE libraries. The fact is that programs that (as I understand it) use kio-fuse (such as Dolphin and Krusader) are not able to access that folder. However, Caja (which I think uses Gnome libraries) does manage to access it, just as it happens from Windows with Filezilla and TotalCommander (as I mentioned in my first message). What else could be the cause of this behaviour of Dolphin and Krusader exclusively? Moreover, I have taken the trouble to install Filezilla on Plasma and try with it exactly the same access procedure to that folder. As expected, it accesses (after 10 or 15 seconds) that folder and displays its contents. I can only mention in this case, that Filezilla shows in the log the message: "Invalid character sequence received, UTF-8 is disabled. Select the UTF-8 option in the site manager to force UTF-8". However, Filezilla, instead of continuing to display the directory tree where the symbolic link is located, "jumps" to base path and displays the tree from which the original path to which the symbolic link points (/nfs/files) is hanging. Caja, on the other hand, does an impeccable job: Not only does it show the contents of the folder, but it also keeps showing the correct directory tree, without jumping to the path to which the symbolic link points.
(In reply to Rafael Linux User from comment #7) > I can't test with an SFTP server because our servers are FTP servers managed > by other teams. In any case, it's clear to me that to be secure or not has > nothing to do with the problem. > > I'm not an expert on KDE libraries. The fact is that programs that (as I > understand it) use kio-fuse (such as Dolphin and Krusader) Dolphin and Krusader use KIO, not kio-fuse. kio-fuse is used for applications which don't use KIO directly, e.g. if you open some file on ftp:// in gedit or similar. So I'd like to reassign this, but I'm not sure whether this is an issue in dolphin or KIO yet. > are not able to > access that folder. However, Caja (which I think uses Gnome libraries) does > manage to access it, just as it happens from Windows with Filezilla and > TotalCommander (as I mentioned in my first message). What else could be the > cause of this behaviour of Dolphin and Krusader exclusively? > > Moreover, I have taken the trouble to install Filezilla on Plasma and try > with it exactly the same access procedure to that folder. As expected, it > accesses (after 10 or 15 seconds) that folder and displays its contents. I > can only mention in this case, that Filezilla shows in the log the message: > "Invalid character sequence received, UTF-8 is disabled. Select the UTF-8 > option in the site manager to force UTF-8". > > However, Filezilla, instead of continuing to display the directory tree > where the symbolic link is located, "jumps" to base path and displays the > tree from which the original path to which the symbolic link points > (/nfs/files) is hanging. > > Caja, on the other hand, does an impeccable job: Not only does it show the > contents of the folder, but it also keeps showing the correct directory > tree, without jumping to the path to which the symbolic link points.
Thank you for the clarification. I also can't tell if it's a problem with kio, kio-fuse, Dolphin or (let's not forget) Krusader. But there is one thing they all have in common: They all use QT libraries. Box and Filezilla don't. The truth is that all my headaches accessing remote files always come from applications that use QT libraries. It is true that many applications that are not based on QT, make it difficult to work with remote files (like Visual Studio Code) but in this particular case, it is not a problem of interoperability between desktops, it is a problem of the QT libraries. Thank you very much for all your help and especially for your quick response, I was pleasantly surprised.
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!
NEEDSINFO is not what I expected. I wrote here all info I can give you about this.
Yep, info got provided.