Created attachment 144588 [details] git for operation can not conntect to huawei share samba STEPS TO REPRODUCE 1. open huawei share and loog press huawei share icon to setting then open share to pc， setting username and password 2. open dolphin, in location input smb://192.168.3.11 and input username and password 3. after clicking confirm the connection, the confirmation connection container will continue to pop up OBSERVED RESULT after clicking confirm the connection, the confirmation connection container will continue to pop up EXPECTED RESULT can connect to huawei share samba. PS: command: smbclient //192.168.9.145/shareitem -U username can conntecd with smbclient in terminal SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 linux kernel: 5.15.6-arch2-1 ADDITIONAL INFORMATION
Created attachment 144589 [details] gif for operation
Comment on attachment 144588 [details] git for operation how to delete this pic？
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves/Debugging_kio_smb#Reporting_Bugs
The content of attachment 144588 [details] has been deleted for the following reason: Removing unrelated data
ystyle@Archlinux ~/Code/Docker/apisix-docker/example master ● export KDE_FORK_SLAVES=1 ystyle@Archlinux ~/Code/Docker/apisix-docker/example master ● export QT_MESSAGE_PATTERN='[%{time process}](%{pid})/(%{category}) %{function}: %{message}' ystyle@Archlinux ~/Code/Docker/apisix-docker/example master ● export QT_LOGGING_RULES='log_kio_smb=true' ystyle@Archlinux ~/Code/Docker/apisix-docker/example master ● dolphin --new-window smb://ystyle@192.168.9.132 [ 0.000](2352588)/(kf.kio.core) unknown: Malformed JSON protocol file for protocol: "trash" , number of the ExtraNames fields should match the number of ExtraTypes fields [ 0.007](2352588)/(kf.kio.core) unknown: Malformed JSON protocol file for protocol: "trash" , number of the ExtraNames fields should match the number of ExtraTypes fields smb_signing_good: BAD SIG: seq 1 smb_signing_good: BAD SIG: seq 3 ystyle@Archlinux ~/Code/Docker/apisix-docker/example master ● dolphin --new-window smb://ystyle@192.168.9.132 [ 0.000](2353618)/(kf.kio.core) unknown: Malformed JSON protocol file for protocol: "trash" , number of the ExtraNames fields should match the number of ExtraTypes fields [ 0.008](2353618)/(kf.kio.core) unknown: Malformed JSON protocol file for protocol: "trash" , number of the ExtraNames fields should match the number of ExtraTypes fields
After the authentication window pops up, click the confirm button, the console does not display other information
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!
Submitted on 2021-12-28
We built now new Plasma for blackPanther OS v22.1 and I can confirm as well, problem still persists on latest Plasma-Desktop:5.23.1 Plasma Workspace:5.90 Dolphin: 21.12.1 Interest: I have two SMB share, Volume_1 and Volume_2, the dolphin discover shares, accept login/passwd I tried enter to Volume_1 I get a endless "Authentication dialog" and can't enter to folder, > smb_signing_good: BAD SIG: seq 1 > smb_signing_good: BAD SIG: seq 3` But! I can simply enter to Volume_2 folder. On another PC, older Plasma/Dolphin still working fine this function for all shares.
I've recheck Dolphin today, so: Login failed another user name/passwod as system user! When I set username/password on NAS to same as local user, I get access to SMB filesystem on nas. When I tried different username+password (already set on nas previously), I get a endless popup "auth dialog" and I can't login. > kf.kio.slaves.smb: libsmb-auth-callback URL: QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: open "smb://nas.localnet/Volume_1" url-type: 3 dirfd: -1 errNum: 13 > kf.kio.slaves.smb: Discovery finished. > kf.kio.slaves.smb: trying checkPassword > kf.kio.slaves.smb: checkPassword for QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: call openPasswordDialog for QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: got password through cache "build" > kf.kio.slaves.smb: openPasswordDialog returned "xMyUserNamex" > kf.kio.slaves.smb: updateCache "/Volume_1" > kf.kio.slaves.smb: Caching info.username = "xMyUserNamex" , info.url = "smb://nas.localnet/Volume_1" > kf.kio.core.dirlister: QUrl("smb://nas.localnet/Volume_1") -> QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.core.dirlister: QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") has not been listed yet. > kf.kio.slaves.smb: QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: checkURL QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: checkURL return3 QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: updateCache "/Volume_1" > kf.kio.slaves.smb: Starting discovery. > kf.kio.slaves.smb: auth_smbc_get_dat: set user= xMyUserNamex , workgroup= PANTHERGROUP server= nas.localnet , share= Volume_1 > kf.kio.slaves.smb: updateCache "/Volume_1" > kf.kio.slaves.smb: libsmb-auth-callback URL: QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: got password through cache "xMyUserNamex" smb_signing_good: BAD SIG: seq 1 smb_signing_good: BAD SIG: seq 3 > kf.kio.slaves.smb: open "smb://xMyUserNamex@nas.localnet/Volume_1" url-type: 3 dirfd: -1 errNum: 1 > kf.kio.slaves.smb: Discovery finished. > kf.kio.slaves.smb: trying checkPassword > kf.kio.slaves.smb: checkPassword for QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: call openPasswordDialog for QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: openPasswordDialog returned "xMyUserNamex" > kf.kio.slaves.smb: updateCache "/Volume_1" > kf.kio.core.dirlister: New redirection url same as old, giving up. > kf.kio.slaves.smb: QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: checkURL QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: checkURL return3 QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: updateCache "/Volume_1" > kf.kio.slaves.smb: Starting discovery. > kf.kio.slaves.smb: auth_smbc_get_dat: set user= xMyUserNamex , workgroup= PANTHERGROUP server= nas.localnet , share= Volume_1 > kf.kio.slaves.smb: updateCache "/Volume_1" > kf.kio.slaves.smb: libsmb-auth-callback URL: QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: got password through cache "xMyUserNamex" smb_signing_good: BAD SIG: seq 1 smb_signing_good: BAD SIG: seq 3 > kf.kio.slaves.smb: open "smb://xMyUserNamex@nas.localnet/Volume_1" url-type: 3 dirfd: -1 errNum: 1 > kf.kio.slaves.smb: Discovery finished. > kf.kio.slaves.smb: trying checkPassword > kf.kio.slaves.smb: checkPassword for QUrl("smb://xMyUserNamex@nas.localnet/Volume_1") > kf.kio.slaves.smb: call openPasswordDialog for QUrl("smb://nas.localnet/Volume_1") > kf.kio.slaves.smb: no value from openPasswordDialog; error: 1 > kf.kio.slaves.smb: user cancelled password request > kf.kio.slaves.smb: errNum 1 I tried a gdb debugging, but I didn't see any more information..
Have you maybe configured a default username password in the Windows Shares section of the system settings? https://i.imgur.com/By26Mgn.png
(In reply to Harald Sitter from comment #11) > Have you maybe configured a default username password in the Windows Shares > section of the system settings? > > https://i.imgur.com/By26Mgn.png no, it's still empty
I suggest you grab a debug log with smb logging enabled https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves/Debugging_kio_smb#Logging_with_libsmbclient_debug_output and take this to https://bugzilla.samba.org for further analysis. The problem seems to be below KIO and dolphin. There is no practical reason from our end why one set of credentials would work while the other does not, much less so if the same credentials work for another volume on the same server. The bad sig stuff certainly seems relevant somehow.