[Samba] problem upgrading 3.0.23->3.0.26

[John H Terpstra]

On Tuesday 29 July 2008 21:43:19 Linda W wrote:
> John H Terpstra wrote:
> > This parameter should be changed from:
> >>          write list = @admin, root
> >
> > to:
> > 	write list = @"BLISS\admin", BLISS\root
>
> ----
> 	Ahh....interesting.
>
> > add:
> > 	guest ok = Yes
> > Also make sure that the guest account (nobody) is able to access
> > the /home/samba/netlogon/%u folders.  In general, use of the %u parameter
> > in a resource that should be accessible by the guest account is
> > potentially problematic.
>
> -----
> 	guest is supposed to be 'nobody'?  Cuz, I have
> guest as uid 998,  and 'nobody'=65534.
> 	Would this create unexpected problems for samba?

Then you need to set in [global]
	guest account = guest

> As for /home/samba/netlogon/%u:
> /home/samba  is 750, u=root, g=samba
> /home/samba/profiles has 755  u+g=root
> I don't have a profile entry for 'nobody' nor 'guest'...do I need one ? 
> even if empty?

No, that is not needed.

> > Why these parameters on the profiles share?
> >
> >>          create mask = 0600
> >>          directory mask = 0700
> >>          store dos attributes = Yes
>
> -----
> 	(They come from the default suse 10.3 file).  I didn't mess w/them.
> 	I don't have any profile dirs anyway, but they seem 'ok'...
> 	(delete?)

Go ahead, delete them.

> > >Why these parameters?
> >
> >          csc policy = disable
> >
> >>          share modes = No
>
> 	Artifacts (deleting)

Good.

> ----
>
> > Add this one:
> > 	profile acls = Yes
>
> --ok
>
> >> [homes]
> >>          comment = Home Dir
> >>          valid users = %S, %D%w%S
> >>          read only = No
> >
> > Why these parameters? Should not be needed.
> >
> >>          create mask = 0750
> >>          inherit acls = Yes
>
> ----
> 	Hmmm.....I may not understand what is meant by acls...  see below where
> you ask why...(answered there)...
>
> >> [home]
> >>          comment = /home (allhomes)
> >>          path = /home
> >
> > What is this? Do you have a group named "trusted_local_net_users"?
> >
> >>          valid users = @trusted_local_net_users, law
>
> (yes; user=trusted & only on local net)...I do on the linux server --
> not on the windows side ....
> note -- several of the places where I have 'law', I was adding the 'id'
>    explicitly, for testing, since groups didn't appear to be working...
>    (i.e. law is in trusted_local_net_users...)....
>
> > Change to:
> > 	valid users = @"BLISS\trusted_local_net_users", BLISS\law
>
> ---ok
>
> > What are the ownership and permissions settings on the /home directory?
>
> "drwxr-xr-x"  root/root

OK, this means that noone (except root) can create or delete a directory in 
the /home directory.

> > Are you seriously allowing users to write to each other's home
> > directories?
> >
> >>          read only = No
>
> ---
> 	Intent was for it to remain under user control -- that's why I use
> the create mask of 0750 (next)....

But this way group members can access each others home directories.  Hmmm.  
I'm sure I would not like that!

> > Why these two parameters? What are you trying to achieve with them?
> >
> >>          create mask = 0750
> >>          inherit acls = Yes
>
> ----
> 	My manpage says inherit acls defaults to off, but the create mask is to
> override the inherit acls setting mode to 0777.  My presumption was that
> acls can be inherited separately.

ACLs are POSIX things.  You can see them using the getfacl utility. They can 
be set using the setfacl utility.  And, they can be set through Windows 
client applications.

> 	I was thinking of acls in a linux sense -- where file mode bits are a
> separate access mechanism from an acl list that uses extended-attributes.
>
> 	At one point, during kernel discussions, acl lists (as with all security
> model insertion points) could only further limit bits set by file mode bits
> -- not give exceptions.  Not sure if it is still that way -- I and others
> argued against it, but were overridden at the time, because the other group
> didn't want the security model insertion
> points to be able to allow more privilege than normal discretionary
> security model would
> allow.  So I was propagating me understanding of how they worked....

Keep your configuration as simple as possible.  Follow the examples in 
Samba3-ByExample.  Chapters 3 or 4 should be as much as you need at your 
site.

http://www.samba.org/samba/docs/Samba3-ByExample.pdf

> >>          browseable = No
> >
> > What ist he purpose of this share? Is this not covered by the homes
> > service?
>
> -----
> 	That's a good question -- I was trying to get
> /home/user to point to a given user's directory
>
> But I also wanted to export the parent as "/homes"....
>
> I kept having problems in this area -- like /homes/ is reserved for 'home',
> but I think I could use /home to mean everyone's home directories -- the
> opposite of what
> I wanted, but that's what I was trying for anyway....

The homes share is really a service that makes a user's home directory 
available from the Windows environment.  Under OpenSUSE/SUSE Linux you could 
set the path like this:

[homes]
	...
	path = /home/%U/Documents
	...

This way the use is kept away from the dit files (.*) and his Windows files 
are in a safe "container" - so to speak.

> >> [%U]
> >>          comment = Home Directory
> >>          path = /home/%U
> >>          valid users = %S, %D%w%S
> >>          read only = No
> >>          create mask = 0750
> >>          inherit acls = Yes
> >>
> >> [Share]
> >>          comment = Share
> >>          path = /Share
> >>          read only = No
> >
> > What are the permissions on the /Share directory?  Why do you need to
> > permit the nobody account to set ACLs on this directory?
> >
> >>          inherit acls = Yes
> >>          guest ok = Yes
>
> ---
> 	I thought I was saying any acls that were created under share would
> propgate downward
> from their locations.  And that guest would be allowed to look at share,
> but by file-
> definitions on /Share, they can't write to them.

Why do you want POSIX ACLs in your Linux file system?  How are you going to 
back them up?  POSIX ACLs are not the same as UGO (user, group, other) 
permissions - they are a superset that sits over the top of UGO permissions.  
Avoid them if you can.

> permissions on /Share=
> 755, u=law, g=wheel;  below /Share any dir's I don't want guest to have
> access to, are
> mode 750, (or 700)...
>
> >> [backups]
> >>          comment = Host backup-dirs
> >>          path = /backups/%m
> >
> > Again, add the domain specifier  (@BLISS\admin). What is the purpose of
> > the "%m" parameter here? It makes no sense/
> >
> >>          write list = @admin, @%m
>
> ----
> 	Oh poo...yeah...  meant to (never got around to it) creating
> groups for each machine name that accessed the Share to include userid's
> that were not admin's (like 'backup'); but never got around to creating a
> user 'backup' to do backups with -- just use an admin signin....
>
> > For the remaining shares, the same questions as above apply.  It is best
> > to keep your configuration simple, then add complexity only as it is
> > proven to be necessary.
>
> ---
>
> 	Well....that's how it started out -- it's just grown warts over time...:-)
> the setup works under the old samba 3.0.23...just haven't kept up with the
> times so well on this server...
>
> > Please show us the output of executing on both servers:
> > 	net groupmap list
>
> ----
> 	Null (no output)

So with Samba-3.0.26 you have Windows groups.  This means that:
	valid users = @"BLISS\law"
will not allow anyone to access the share because there is no law group un 
Windows.

So here is how you can solve that:

	#root > groupadd law
	#root> net groupmap add unixgroup=law ntgroup=law type=domain

Then you will have a group called "law" both for Windows clients and in the 
Linux OS.

What groups do your users belong to?  By adding Linux (POSIX) users to the 
group law, they will be members of the Windows group "law" also.

> > Also, what is the output of?:
> > 	net getdomainsid
>
> SID for domain ISHTAR is: S-1-5-21-3865964499-331234528-1442996297
> SID for domain BLISS is: S-1-5-21-3865964499-331234528-1442996297

That's a good output!

You should also learn how to set the "log level", collect log file per client 
machine, etc. so that you can diagnose why connection attempts are failing.  
Here's a snippet:

[global]
	...
	log level = 3
	max log size = 0
	log file = /var/log/samba/%L-%m.log
	...

This will result in a separate log file for each server alias name that is 
accessed by each windows client.

Cheers,
John T.