[Samba] Looking for a set of definitive answers (long)
udo.rader at bestsolution.at
Fri May 23 23:00:31 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Avery Payne wrote:
> - 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the samba