Bug 421228 - Dolphin can't show files from SMB1 share properly
Summary: Dolphin can't show files from SMB1 share properly
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 20.04.0
Platform: Archlinux Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-09 14:31 UTC by Sebastian Hirsch
Modified: 2020-05-22 10:40 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
File shown as folder and failed to open (81.45 KB, image/png)
2020-05-09 14:31 UTC, Sebastian Hirsch
Details
Dir command for ressource (52.66 KB, image/png)
2020-05-12 15:39 UTC, Sebastian Hirsch
Details
stat command for the ressource (40.02 KB, image/png)
2020-05-12 15:40 UTC, Sebastian Hirsch
Details
extra debug patch (1.05 KB, patch)
2020-05-13 11:57 UTC, Harald Sitter
Details
kio-extras-smb-log (175.67 KB, text/plain)
2020-05-13 15:04 UTC, Sebastian Hirsch
Details
okular error (88.29 KB, image/png)
2020-05-13 15:04 UTC, Sebastian Hirsch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Hirsch 2020-05-09 14:31:59 UTC
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.
Comment 1 Sebastian Hirsch 2020-05-09 14:42:34 UTC
Additional note: Getting the files with FTP from dolphin works fine by the way.
Comment 2 Sebastian Hirsch 2020-05-10 08:33:33 UTC
Another additional note: Mounting the SMB1 share with smb4k works as intended, so the issue must be dolphins handling of the share.
Comment 3 Harald Sitter 2020-05-11 18:50:57 UTC
what's the version of libsmbclient?
Comment 4 Sebastian Hirsch 2020-05-11 19:32:22 UTC
Do you mean the smbclient package of Archlinux? That is at version 4.12.2-3.
Comment 5 Harald Sitter 2020-05-12 13:58:53 UTC
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
Comment 6 Sebastian Hirsch 2020-05-12 15:39:48 UTC
Created attachment 128395 [details]
Dir command for ressource
Comment 7 Sebastian Hirsch 2020-05-12 15:40:18 UTC
Created attachment 128396 [details]
stat command for the ressource
Comment 8 Sebastian Hirsch 2020-05-12 15:41:15 UTC
I have added two screenshots with the results of the commands.
Comment 9 Harald Sitter 2020-05-13 10:29:04 UTC
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.
Comment 10 Sebastian Hirsch 2020-05-13 10:32:48 UTC
(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?
Comment 11 Harald Sitter 2020-05-13 11:57:56 UTC
Created attachment 128420 [details]
extra debug patch
Comment 12 Antonio Rojas 2020-05-13 12:02:33 UTC
(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
Comment 13 Harald Sitter 2020-05-13 12:30:53 UTC
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.
Comment 14 Sebastian Hirsch 2020-05-13 12:32:19 UTC
Thanks for all your help! I will try to debug the issue as soon as I can.
Comment 15 Sebastian Hirsch 2020-05-13 15:03:25 UTC
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.
Comment 16 Sebastian Hirsch 2020-05-13 15:04:20 UTC
Created attachment 128425 [details]
kio-extras-smb-log
Comment 17 Sebastian Hirsch 2020-05-13 15:04:55 UTC
Created attachment 128426 [details]
okular error
Comment 18 Harald Sitter 2020-05-14 11:48:39 UTC
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
Comment 19 Sebastian Hirsch 2020-05-14 11:53:53 UTC
(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.
Comment 20 Sebastian Hirsch 2020-05-22 10:40:37 UTC
As an headsup:
Arch updated Samba to version 4.12.3 and that fixed my issues.