Bug 103673 - smb authentication always fails in Konqueror
Summary: smb authentication always fails in Konqueror
Status: RESOLVED DUPLICATE of bug 103212
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: smb (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 103940 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-11 17:58 UTC by dowobeha
Modified: 2005-05-18 08:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dowobeha 2005-04-11 17:58:21 UTC
Version:           3.4.0-2.0.rhel3.kde (using KDE 3.4.0-1.3.rhel3.kde, CentOS release 3.4 (final))
Compiler:          gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)
OS:                Linux (i686) release 2.4.21-27.0.2.EL

Attempts to log in to samba shares using smb://username@server/share in Konqueror always fail. 

Problem has been observed when attempting to access smb shares on Windows XP and on IBM i5/OS (IBM iSeries).

Steps to reproduce:

* Open Konqueror
* Enter URL of smb share in format smb://username@server/share
* Authentication window pops up
* Enter password in authentication window.
* Click OK or hit Enter

At this point the authentication window refreshes, and the password field is blank. Re-entering the password results in same behavior. Clicking cancel returns an error message on the Konqueror main window:

An error occurred while loading smb://username@server/share:
Access denied to smb://username@server/share.


Using mount in konsole to mount the smb share using the same username and password succeeds. Actual command used:

sudo mount -t smbfs -o username=username,password=mypwd //server/share /home/localuser/mountpoint
Comment 1 Thiago Macieira 2005-04-12 00:59:31 UTC
smb://DOMAIN\username@servername/share/ works fine for me, on a Windows 2000 server and on a Linux (Samba) server.
Comment 2 dowobeha 2005-04-14 21:16:12 UTC
UPDATE - I am able to get to a Windows XP box by doing the following:

* Open Konqueror
* Enter URL of smb:/ and hit Enter
* Click on the workgroup of the Windoxs XP box
* Click on the server
* Enter username and password in authentication window.
* Click OK or hit Enter.


Once I have followed this procedure, I can quit Konqueror, re-launch Konqueror, and succeed in accessing the XP box using the procedure outline in my original post (smb://username@SERVER/share), provided that I type the server name in upper case.

However, attempting to log in directly (as per original post) prior to following the (smb:/ then click) procedure fails. Also, log in attempts using lowercase server name even after performing the (smb:/ then click) procedure also fail.

I don't know the workgroup name for some of the servers. I'll try to find out.

Thiago, when you posted, did you mean DOMAIN or did you mean WORKGROUP?

Lane
Comment 3 Thiago Macieira 2005-04-15 05:07:15 UTC
Whichever. A domain is a workgroup with a PDC.
Comment 4 Thiago Macieira 2005-04-15 12:37:07 UTC
*** Bug 103940 has been marked as a duplicate of this bug. ***
Comment 5 Torles 2005-04-15 13:38:40 UTC
Reproduced the bug on a server belonging to a WORKGROUP and on a server belonging to a DOMAIN (with PDC)

Upper case work, not lower case.

in addition : tested on Kubuntu 5.04
Comment 6 jeff pitman 2005-05-13 18:15:31 UTC
samba = 3.0.14; kde = 3.4.0

Still broke. Here's how I worked around it:

smb://DOMAIN\username:password/share

If you don't put password in, the authentication box will keep opening even though the correct password is entered.  The above work around only works on a per-directory basis.  Each subdir you enter will need to re-issue the same tricky url.

I hope someone can fix this... tres annoying.
Comment 7 jeff pitman 2005-05-13 18:17:19 UTC
oh and bug #103212 is the same thing.  One of these will need to be duped.
Comment 8 Thiago Macieira 2005-05-14 01:47:33 UTC
The other one is in state ASSIGNED.

*** This bug has been marked as a duplicate of 103212 ***