[Samba] Looking for a set of definitive answers (long)

[Udo Rader]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Avery Payne wrote:
> Question:
> 
> - File permissions do not behave as expected (from the viewpoint of other 
> staff working with the server).
> 
> The *nix permission bits cause a user, group, and "Everyone" entry to 
> become permanent and persistent.  There was some initial grousing over 
> this fact as our long-time Windows admin scratched his head over why he 
> couldn't remove these entries as he saw fit.  After explaining that there 
> would always be three settings no matter what, that they could never be 
> deleted, and that they represented actual filesystem-level bits that 
> wouldn't go away, it was accepted.  I didn't notice if this was in the 
> docs or not, but I certainly didn't find it.  It also meant enabling ACLs 
> on all of the filesystems and doing some creative thinking with the 
> permissions.  The closest I could do was to map all files as owner root, 
> group set to Domain Admins, and Everyone set to disallowed; members of 
> the IT staff would be mapped with the "admin users" parameter; from 
> there, any additional permissions would be mapped via ACLs.  We've found 
> that this method has the closest behavior to a "real" Windows server and 
> has satisfied everyone.

that's expected behaviour ;-)

As you might now, things may even get more complicated if you have "dos
filemode = yes" and maybe "map system/hidden/archive = yes" ...

> - Permissions don't propigate through the filesystem.
> 
> On a Real Windows Box(tm) you would be able to set permissions at the 
> parent level of a directory and have them show up for each child object.  
> Because the filesystem semantics are not the same in *nix-land, you need 
> to go into the directly and manually propigate the permissions, or if 
> you're stuck trying to administer permissions through a windows session 
> (like the other IT staffers in my department), using the Advanced setting 
> to force-reset all permissions on all child objects.  This has also 
> caused a bit of grousing as we have several nested directories with a 
> heiarchy of permissions; getting one parent directory wrong means 
> rebuilding permissions for several child directories as well.  I have 
> never been able to get a satisfactory answer as to how to resolve this 
> issue, other than the process I described above (which I had to resolve 
> for myself without documentation).

do you have "inherit acls = yes" and "map acl inherit = yes" in your
smb.conf?

that usually does the trick ...

> - The vendor initially set up our authentication via tdb files and 
> Winbind.  We have been using this combination succesfully for some time, 
> but in the Official Samba Guide it talks about regular maintenance of the 
> tdb files via tdbbackup.  The department head has asked that I find the 
> definitive answer on how to do this, as we cannot afford more than a few 
> minutes of scheduled downtime.  The vendor's response was that tdb files 
> should not be used because they can be corrupted when applying tdbbackup 
> to them (despite the fact that it was the vendor that set us up to use 
> them to begin with - go figure).  This has caused even more concern - 
> millions of dollars in business and 50+ users are supported by this 
> server, running 24/7/365.  So, if we were to loose our file server 
> tomorrow, and had to activate the backup server (which we would do by 
> plugging in the eSATA array into the new units and starting up the 
> system), how could we guarantee that the GUIDs, etc. would be consistent 
> and we wouldn't have a complete mess on our hands?  I have seen someone 
> else recently mention that they should be using an LDAP authentication 
> backend.  So who's correct, the vendor's original setup which uses tdb 
> files, or the 2nd vendor response which says don't use them, or should we 
> be on LDAP authentication connected to our Win2k3 domain controllers?

well, I have to agree with the second response you got. LDAP or let's
say "any" replicable & (load) balancable database storage is far better
than a local file based storage.

I've done many installations and even for the smallest ones I used LDAP,
slapd for true samba PDC installations or of course the nice ADS(=LDAP)
features any >= w2k PDC provides.

BTW, providing your smb.conf or actually the output of testparm would be
 a good start point to get better feedback on what goes wrong with your
installation.

- --
Udo Rader
http://www.bestsolution.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkg3TIwACgkQJkMMup66A9wXxgCgltybmy/83SPzFX0zgDwN/vPN
ObsAnRYWzgnb7EsD/1eOqovrztDeAZjI
=j5As
-----END PGP SIGNATURE-----