Summary: | Dolphin can't show files from SMB1 share properly | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | Sebastian Hirsch <klaussemmler> |
Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arojas, kfm-devel, nate, sitter |
Priority: | NOR | ||
Version: | 20.04.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
File shown as folder and failed to open
Dir command for ressource stat command for the ressource extra debug patch kio-extras-smb-log okular error |
Additional note: Getting the files with FTP from dolphin works fine by the way. Another additional note: Mounting the SMB1 share with smb4k works as intended, so the issue must be dolphins handling of the share. what's the version of libsmbclient? Do you mean the smbclient package of Archlinux? That is at version 4.12.2-3. Very strange. Unfortunately I don't think there's any useful debug output to be had for this. Type determination happens entirely within libsmbclient. What's the output of smbclient -U frittencloud -D 'cloud/Anleitung Onkyo Receiver' -c dir //fritz-nas/Frittenwolke and smbclient -U frittencloud -D 'cloud/Anleitung Onkyo Receiver' -c 'stat Manual_TX-8020-ItDeNlSv' //fritz-nas/Frittenwolke Created attachment 128395 [details]
Dir command for ressource
Created attachment 128396 [details]
stat command for the ressource
I have added two screenshots with the results of the commands. At least smbclient gets the type right. Are you by any chance set up to build something from source? I'm afraid we'll need some new debug output to get to the bottom of this. (In reply to Harald Sitter from comment #9) > At least smbclient gets the type right. > > Are you by any chance set up to build something from source? I'm afraid > we'll need some new debug output to get to the bottom of this. Sadly i'm not setup to build from source. What can i do to build from source? Are there some directions to do so without breaking my current plasma and dolphin? Created attachment 128420 [details]
extra debug patch
(In reply to Harald Sitter from comment #9) > At least smbclient gets the type right. > > Are you by any chance set up to build something from source? I'm afraid > we'll need some new debug output to get to the bottom of this. * Install asp and pacman-contrib * Run 'asp checkout kio-extras' * Save the patch in the kio-extras/trunk dir * cd kio-extras/trunk * Edit PKGBUILD to add the patch name to the source() array, and add ' patch -p1 -i ../patch-file-name' in the prepare() section * Run 'updpkgsums' and 'makepkg -si' * When you are done debugging, reinstall the original kio-extras package with pacman Thanks, Antonio! Sebastian, once you've managed to build kio-extras with the patch I've attached please follow this: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves/Debugging_kio_smb#Logging to get a debug log of dolphin when you navigate to that pdf. Should you fail to build kio-extras do tell us anyway. Thanks for all your help! I will try to debug the issue as soon as I can. I could build kio-extras just fine, thanks Antonio! I have attached the log as a text file as its really huge. I also made a screenshot from when I tried to open the pdf with okular. Its in german so tell if I should translate the message for you. Created attachment 128425 [details]
kio-extras-smb-log
Created attachment 128426 [details]
okular error
I think I have all the info I need, thanks. That is one crazy issue though... What happens is that we list the directory contents and it gets correctly detected as a regular file > log_kio_smb: [ "UDS_NAME"="Manual_TX-8020_ItDeNlSv.pdf" "UDS_FILE_TYPE"=32768 "UDS_SIZE"=22967500 "UDS_MODIFICATION_TIME"=1576488632 "UDS_ACCESS_TIME"=1576488632 ] after that we do get details on the directory for one reason or another, which as one would expect is reporting it is a directory > log_kio_smb: [ "UDS_NAME"="." "UDS_FILE_TYPE"=16384 "UDS_SIZE"=0 "UDS_MODIFICATION_TIME"=1586423295 "UDS_ACCESS_TIME"=1588930044 ] we then get details on the file and now the file suddenly is a directory :O > log_kio_smb: [ "UDS_NAME"="Manual_TX-8020_ItDeNlSv.pdf" "UDS_FILE_TYPE"=16384 "UDS_SIZE"=0 "UDS_MODIFICATION_TIME"=1586423295 "UDS_ACCESS_TIME"=1588930044 ] What I suspect happens is that libsmbclient internally has a caching problem of some sort. The data we get on the file the second time around looks suspiciously similar to the data of the directory (mtime and atime are the same). That theory is further supported by it suddenly getting reported as a file again on a request shortly afterwards. I've filed a bug report on samba about this. https://bugzilla.samba.org/show_bug.cgi?id=14379 (In reply to Harald Sitter from comment #18) > I think I have all the info I need, thanks. > > That is one crazy issue though... > > What happens is that we list the directory contents and it gets correctly > detected as a regular file > > > log_kio_smb: [ "UDS_NAME"="Manual_TX-8020_ItDeNlSv.pdf" "UDS_FILE_TYPE"=32768 "UDS_SIZE"=22967500 "UDS_MODIFICATION_TIME"=1576488632 "UDS_ACCESS_TIME"=1576488632 ] > > after that we do get details on the directory for one reason or another, > which as one would expect is reporting it is a directory > > > log_kio_smb: [ "UDS_NAME"="." "UDS_FILE_TYPE"=16384 "UDS_SIZE"=0 "UDS_MODIFICATION_TIME"=1586423295 "UDS_ACCESS_TIME"=1588930044 ] > > we then get details on the file and now the file suddenly is a directory :O > > > log_kio_smb: [ "UDS_NAME"="Manual_TX-8020_ItDeNlSv.pdf" "UDS_FILE_TYPE"=16384 "UDS_SIZE"=0 "UDS_MODIFICATION_TIME"=1586423295 "UDS_ACCESS_TIME"=1588930044 ] > > What I suspect happens is that libsmbclient internally has a caching problem > of some sort. The data we get on the file the second time around looks > suspiciously similar to the data of the directory (mtime and atime are the > same). > That theory is further supported by it suddenly getting reported as a file > again on a request shortly afterwards. > > I've filed a bug report on samba about this. > https://bugzilla.samba.org/show_bug.cgi?id=14379 Thanks a lot for your investigation! Lets see if this issue gets fixed. As an headsup: Arch updated Samba to version 4.12.3 and that fixed my issues. |
Created attachment 128286 [details] File shown as folder and failed to open SUMMARY I currently have an issue with a SMB1 share (Fritzbox Fritz!NAS). I can log into my share and it shows all folders and files, but for some reason, some files get shown as folder and when i want to open them, it fails. I have attached an image to show my issue. STEPS TO REPRODUCE 1. Open Dolphin 2. Open the SMB1 share 3. Look for files that get shown as folders and try to open them OBSERVED RESULT Files get shown as folders and fail to open. EXPECTED RESULT Files get shown as files and open in the correct application. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.69 Qt Version: 5.14.2 ADDITIONAL INFORMATION It has to be an SMB1 share and i can only test with a fritzbox 6660 cable router. My Desktop uses Samba version 4.12.2 and I enabled the SMB1 support in the smb.conf config file.