On 03/11/2014 07:13 PM, Ken Dibble wrote:
Below is the smb.conf file ON THE *FILE* SERVER.
"Public" is the share that the Mac user cannot connect to. You
will see that security is deferred to the domain. You will also
see that, unlike most shares on the SPOCK file server, there is no
specified list of allowed users for the Public share. This is
because there are nearly 100 domain users who access that share,
and right now I don't need to (and do NOT want to) have to
add/remove them individually for that share.
[global]
load printers = yes
cups options = raw
netbios name = Spock
server string = STIC File Server
default = data
workgroup = STIC
os level = 20
winbind trusted domains only = yes
security = domain
I have my smb.conf set to security = user. I then add users,
passwords, and smb.conf entries to grant users permission to access
needed shares. Your |smb.conf|parameter, Security = domain, does
not really make samba behave as a domain controller. This setting
means we want samba to be a domain member. Your system is probably
running a windows primary domain server, with a domain name of
Spock, of which your CentOS samba server is a member. Your problem
might be that a Mac cannot join a windows Domain. Have you tried
any of the samba forums?
Whoops, I should have said "Your system is probably running a windows
primary domain server within the STIC domain of which Spock, (eg your
Linux samba server), is a member.
You might check to see if there is a Mac utility, that can be run
from the command line, to help debut a connection to a Linux samba
server.
Such a tool might return a hint of the problem.
I am using a SAMBA 3 domain. There is NO WINDOWS domain server. The
name of the domain controller is KIRK. That machine is running
ClearOS, which is a version of CentOS that is designed to function as
an old-style, NT-compliant domain controller. SAMBA 3 emulates the
domain controller function. (SAMBA 4 can emulate a Windows Active
Directory domain.) NO Windows is required, or in use.
SPOCK is NOT the domain controller. SPOCK is just a file server on the
domain. As I understand it, the parameter
security = domain
causes the server SPOCK to refer credentialling issues to the domain
controller KIRK. I do not expect it to make SPOCK into a domain
controller.
I WANT to have the domain control security for the Public share on
SPOCK because I have nearly 100 (ONE HUNDRED!!!) domain users, whose
credentials I do NOT want to have to set up manually for this share.
Using a domain to control access to the Public share gets me out of
having to do that.
OK. You have [ security = Domain ], which requires all samba logins to
be coordinated with the Windows Primary Domain Controller, and then you
override that by setting the share to public, which implies everyone can
access the share regardless of username and password, thus avoiding
coordination with the Windows Primary Domain Controller.
What would happen if you went to [ security = user ] and had the share
set to public? That might result in nobody being able to access the
share, so I'd research that suggestion very carefully before taking any
action. LOL It was just a thought. Also, you might explore how using
the guest user might eliminate the problem of needing to add and
maintain hundreds of users. That might be equivalent to making the
share public, which also avoid having each user enter a name and password.
Still, these changes may not solve the problem you're having with giving
the Mac user access. We still haven't nailed down the cause of the
current effects your experiencing with the Mac authentication, but it
might point us in the direction of the problem. Also, if the CentOS
samba server can be detached form the windows domain, we could set [
Server role: ROLE_STANDALONE ], which might give us more flexibility.
Regards,
LelandJ
Maybe this is just impossible. I knew I should have made the guy
accept a Windows machine instead of insisting on bringing in his Mac. :)
Ken Dibble
www.stic-cil.org
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
