Bug 302595 - KIO: smb://user@server doesn't use that username
Summary: KIO: smb://user@server doesn't use that username
Status: RESOLVED WORKSFORME
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: smb (show other bugs)
Version: unspecified
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-26 20:07 UTC by Jeffrey
Modified: 2017-10-30 15:16 UTC (History)
2 users (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 Jeffrey 2012-06-26 20:07:02 UTC
KDE 4.8.3 n Debian Sid

Specifying in Dolphin the connection string as
smb://user@server

Dolphin does not use that username and does not prompt for a password, and instead uses my own desktop username 'eljefe' to tie into that remote machine's 'eljefe' account.

If I enter the string like this:
smb://user:pass@server
Dolphin does then seem to use that remote username, but Dolphin shows permissions/owner as being my local username (eljefe) even though the connection is with a different username.

Reproducible: Always

Steps to Reproduce:
1. Try to connect to Samba share with smb://user@server
2. Browsing perms are based on my desktop user account's permission on that remote machine account
3. Newly created files are created with my own user account rather than the specified account (based on created file permissions as reported on the Samba/CIFS server, ls -la)
Actual Results:  
I am forced to browse with my own account (on that remote machine) rather than the account which I specified.

Expected Results:  
I should be prompted for the specified account's password and then browsing would be with that remote account's perms.  If i create a file or directory, it shows as being created by my local/remote account, not the specified remote account.

smb.conf on remote server:

[global]
workgroup = OFFICE
server string = CIFS00.OFFICE File Share
server string = %h server
unix extensions  = No
follow symlinks = Yes
wide links = Yes
locking = yes
strict locking = no
security = user
encrypt passwords = true
passdb backend = ldapsam:"ldaps://10.10.10.220:636 ldaps://10.10.10.119:636"
ldap ssl = off
ldap admin dn = uid=rootuser,dc=network,dc=net
ldap suffix = dc=network, dc=net
ldap group suffix = ou=Group
ldap user suffix = ou=People
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=People
obey pam restrictions = yes
unix password sync = yes

[public]
comment = X Drive
path = /space/public
public = yes
writable = yes
printable = no
create mask = 0775
create mask = 0664
create mode = 0664
directory mask = 0775
force directory mode = 0775
directory security mask = 0775
group = staff
force group = staff
Comment 1 Nate Graham 2017-10-28 17:22:41 UTC
Weird. I definitely don't see this behavior today. Can you still reproduce using more modern software?
Comment 2 Jeffrey 2017-10-30 15:12:15 UTC
Hi, I don't seem to have this issue any longer. It's been a while and things are working well. Close it up! Thanks for checking in.
Comment 3 Nate Graham 2017-10-30 15:16:15 UTC
Fantastic!