-----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----- -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba