Bug 4210 - Domain prefix on "force user" value fails
Summary: Domain prefix on "force user" value fails
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Config Files (show other bugs)
Version: 3.0.23c
Hardware: x86 Windows XP
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-06 14:02 UTC by Bill Greene
Modified: 2008-07-01 15:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Greene 2006-11-06 14:02:29 UTC
Environment:  Fedora Core 5 with all updates, Samba 3.0.23c, winbind is mapping domain users and groups (idmap rid).

We have a share with a definition like:

[computerclub]
        path = /home/D13/computerclub
        valid users = "D13\administrator" "D13\computerclub" "D13\cmueller"
        force user = "D13\computerclub"
        writeable = yes

This works in as expected in 3.0.23a.  In 3.0.23c, we get an error when trying to access the share from Windows.  When we try using smbclient we get:

$ smbclient //wfserver/computerclub -U computerclub
Password: 
Domain=[D13] OS=[Unix] Server=[Samba 3.0.23c-1.fc5]
tree connect failed: Call returned zero bytes (EOF)

The problem is associated with the "force user" statement.  If I comment it out, I can connect.  Pointing it to a "real" Linux user (e.g., "nobody") works.  valid users working correctly.  It appears as though the problem is having a domain prefix on the forced user.

ls -l shows the directory and everything in it as owned by D13\computerclub, so the host side is seeing the user correctly.

Thanks!
Comment 1 Misty Stanley-Jones 2008-07-01 15:55:48 UTC
I saw this just last night in 3.0.28a on Ubuntu 8.04.  Both the and "force group" and "valid users=@DOMAIN\group" directives failed to be evaluated.  The group was not expanded to its members, so if a valid member of a group tried to access a share, access was denied.  If "valid users = DOMAIN\user" was used, the user could access the share.  Because it was 3:30AM when we realized what was going on, I reverted back to 3.0.24 and everything seems to be working.  I can file a new bug report on this if necessary and try to make a test system to replicate it.

John Terpstra actually discovered the problem.