Re: [Samba] Looking for a set of definitive answers (long)
-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
Re: [Samba] Looking for a set of definitive answers (long)
On Fri, May 23, 2008 at 5:59 PM, Jeremy Allison <[EMAIL PROTECTED]> wrote: > On Fri, May 23, 2008 at 04:30:57PM -0400, David Eisner wrote: >> On Thu, May 22, 2008 at 4:59 AM, Chris Osicki >> <[EMAIL PROTECTED]> wrote: >> >> >> >> - Permissions don't propigate through the filesystem. >> >> >> > >> > With POSIX ACL's they do. Take a look at "default ACL", it defines >> > permissions >> > newly created files/directories inherits from their parent directory. >> >> With Windows 2000+ (I believe), the inheritance is dynamic: changes >> higher up in the tree can affect the permissions of child objects even >> after they are created. (See http://support.microsoft.com/kb/223441 >> for example). > > No, that's not how it works. It's how it's spec'ed, but > the client actually runs down the tree doing the changes, > not the server. > > So Samba would work the same way (ie. the Windows client will > do the permissions change walk down the tree against > a Samba server as it would against a Windows server). > > Jeremy. I'll check again. There's a bug where the "Allow inheritable permissions from the parent to propagate to this object and all child objects." checkbox immediately rechecks itself when it is unchecked[1]. It's been awhile, but when I looked at the code, it seemed to be related to this issue, particularly with smbd/posix_acls.c/append_parent_acl() clobbering the flag. Even when I changed the code so that the value of the flag was preserved, smbd (as you suggest) did not propagate the changes down the tree. That is, unchecking the inheritance flag did not in fact result in the inherited ACL entries being removed. Apparently the windows client didn't do the recursive removal, either. -David [1] https://bugzilla.samba.org/show_bug.cgi?id=5052 -- David Eisner http://cradle.brokenglass.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Looking for a set of definitive answers (long)
On Fri, May 23, 2008 at 04:30:57PM -0400, David Eisner wrote: > On Thu, May 22, 2008 at 4:59 AM, Chris Osicki > <[EMAIL PROTECTED]> wrote: > >> > >> - Permissions don't propigate through the filesystem. > >> > > > > With POSIX ACL's they do. Take a look at "default ACL", it defines > > permissions > > newly created files/directories inherits from their parent directory. > > With Windows 2000+ (I believe), the inheritance is dynamic: changes > higher up in the tree can affect the permissions of child objects even > after they are created. (See http://support.microsoft.com/kb/223441 > for example). No, that's not how it works. It's how it's spec'ed, but the client actually runs down the tree doing the changes, not the server. So Samba would work the same way (ie. the Windows client will do the permissions change walk down the tree against a Samba server as it would against a Windows server). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Looking for a set of definitive answers (long)
On Thu, May 22, 2008 at 4:59 AM, Chris Osicki <[EMAIL PROTECTED]> wrote: >> >> - Permissions don't propigate through the filesystem. >> > > With POSIX ACL's they do. Take a look at "default ACL", it defines permissions > newly created files/directories inherits from their parent directory. With Windows 2000+ (I believe), the inheritance is dynamic: changes higher up in the tree can affect the permissions of child objects even after they are created. (See http://support.microsoft.com/kb/223441 for example). -David -- David Eisner http://cradle.brokenglass.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Looking for a set of definitive answers (long)
On Wed, 21 May 2008 18:47:52 + (UTC) Avery Payne <[EMAIL PROTECTED]> wrote: > Question: > > We recently moved to a Samba-based file server, which holds mission- > critical data on it (.dbf files used by our Accounting software, etc.) > The goal was to create a file server that had excellent performance while > providing Volume Management, but we felt that something like Veritas was > overkill for our needs. > > Design Goals: > - Redundant Hardware > - Manual Failover (this was an acceptable solution) > - Very large storage capacity (minimum 1 Terabyte) > - Better than 100Mbyte/sec throughput > - Volume Management, Journaled Filesystem > - Drop-In Replacement for aging Win2k file server > - Use existing admin tools to avoid retraining [snip] > > - Permissions don't propigate through the filesystem. > With POSIX ACL's they do. Take a look at "default ACL", it defines permissions newly created files/directories inherits from their parent directory. I might be misunderstanding your complains, though. My Windows know-how is limited to an absolute minimum necessary to survive in the wild world out there ;-) As for the winbind and tdb files: if you fail over to the standby server you don't have your SID to UID/GID mappings anymore, unless you copy then somehow over. The LDAP backend for winbind is a great feature and I would suggest you to take it into consideration. I run several Samba instances on few Linux clusters with a SunOne Ldap "cluster" as backend and it works very well (touching wood ;-) Thanks and regards, Chris -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Looking for a set of definitive answers (long)
Avery, OK - I'll respond too. I see Jeremy has beaten me to it. Let me tell you up front, if you want the documentation to be improved the best thing you can do is contribute changes and updates. Making us aware of docuentation problems is a good start, but please take this a step further - send us your updates and changes. One other thing, before I get too far into answer or commenting is this: The Official Samba3 HOWTO and Reference Guide (TOSHARG) is a document (book) that sets out how specific parts of Samba function. It was never intended to provide a working template or a scripted recipe. I did write the Samba3-ByExample book with the specific objective to provide detailed step-by-step, fully worked, examples of real working networks, did you consult that document at any time? Are you offering to improve its value and utility by contributing your experiences and recommendations? Users and admins like yourself are in the best position to improve the documentation. Please see comments below. Chees, John T. On Wednesday 21 May 2008 01:47:52 pm Avery Payne wrote: > Question: > > We recently moved to a Samba-based file server, which holds mission- > critical data on it (.dbf files used by our Accounting software, etc.) > The goal was to create a file server that had excellent performance while > providing Volume Management, but we felt that something like Veritas was > overkill for our needs. A noble goal that can be achieved. > Design Goals: > - Redundant Hardware > - Manual Failover (this was an acceptable solution) > - Very large storage capacity (minimum 1 Terabyte) > - Better than 100Mbyte/sec throughput > - Volume Management, Journaled Filesystem > - Drop-In Replacement for aging Win2k file server > - Use existing admin tools to avoid retraining The last two goals are a little ambitious. A drop-in replacement is a tall order that I believe can not be met today. There are some existing tools, but none are a complete replacement for the nicely integrated Microsoft toolset. > The proposed solution was a Samba file server running on a pair of > redundant servers, with one connected to an eSATA raid box, with LVM and > Ext3 providing volume management and journaling. I would not architect the solution this way. There are way too many pitfals with this solution. You have identified one already - the SID <=> UID/GID mapping challenge. I would have used a RAID5 array in each server with rsync to synchronize from the master to the slave. This could be run from cron. Anyhow, this is a digression from your problems. > Our transition was a > bit rough, but in the end it has been very stable and fast. We have been > really pleased with the performance of the hardware/software combo, > seeing sustained throughput of about 250Mbyte/sec with peaks as high as > 300Mbyte/sec. But along the way, we encountered some oddities, and I > have some remaining questions. What lab work did you do in a test environment before rolling this life? Proper pre-rollout evaluation can save a lot of head-banging later. > First, the oddities (long-time Samba devs and admins, take this with a > grain of salt, when I say oddity I mean it from the perspective of an > experienced Windows administrator): Grain of salt taken. Your initiative to write this email is most appreciated. It is a first step in the process of improvement. > - 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. Samba is an engine that sits on top of a host OS. That host OS is NOT Windows. Samba has to go along with the rules imposed by the host OS. The TOSHARG chapter on "File, Directory, and Share Access Controls" should be the red flag that underlying file system semantics are exerted by Samba. Windows admins need to be trained to understand that Samba is not Windows NT/2Kx, etc. Jeremy's notes about the VFS modular work aimed at providing better Windows ACLs emulation may provide the solution you are looking for. > 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 would help me to understand your problem if you can point out how you went about searching for answers. What questions did you frame mentally in your search? Where and how did you look? Did you use a hard-copy of the book? Search online in the HTML web pages? Or did you download the PDF of the book and use the hotlinked pages in the subject and topic indexes? > It
Re: [Samba] Looking for a set of definitive answers (long)
On Wed, May 21, 2008 at 06:47:52PM +, Avery Payne wrote: > Question: > > We recently moved to a Samba-based file server, which holds mission- > critical data on it (.dbf files used by our Accounting software, etc.) > The goal was to create a file server that had excellent performance while > providing Volume Management, but we felt that something like Veritas was > overkill for our needs. > > Design Goals: > - Redundant Hardware > - Manual Failover (this was an acceptable solution) > - Very large storage capacity (minimum 1 Terabyte) > - Better than 100Mbyte/sec throughput > - Volume Management, Journaled Filesystem > - Drop-In Replacement for aging Win2k file server > - Use existing admin tools to avoid retraining > > > The proposed solution was a Samba file server running on a pair of > redundant servers, with one connected to an eSATA raid box, with LVM and > Ext3 providing volume management and journaling. Our transition was a > bit rough, but in the end it has been very stable and fast. We have been > really pleased with the performance of the hardware/software combo, > seeing sustained throughput of about 250Mbyte/sec with peaks as high as > 300Mbyte/sec. But along the way, we encountered some oddities, and I > have some remaining questions. > > First, the oddities (long-time Samba devs and admins, take this with a > grain of salt, when I say oddity I mean it from the perspective of an > experienced Windows administrator): Great post, thanks for writing it ! I always appreciate it when users come and tell us about their experiences, and where we can improve. Now onto the specifics: > - File permissions do not behave as expected (from the viewpoint of other > staff working with the server). Yes, ACLs are just different between UNIX & Windows. We map Windows ACLs onto POSIX as best as we can, but the mapping is not perfect. The goal is to make the two common cases : "these groups and user fred have access", and "these groups but *not* user fred have access" as intuitive as possible. For 3.3 we're planning to overlay a Windows ACL model that will allow perfect Windows ACL restrictions to be added to Samba, but not perfect Windows ACL allowances (ie. we'll store the Windows ACLs and use them to restrict access early on access denied returns, but still map down to POSIX to allow the underlying file permissions to take effect). Hopefully this might help you. > - To oplock or not to oplock: that is the question > > The documentation is not entirely clear about when you should and > shouldn't use oplocks on shared files. It would have been much simplier > (IMHO) to simply say "use your best judgement, BUT if you are using > shared data files like Access or Excel or DBF's, you will want to disable > them or you'll have problems!". Yes those words show up on newsgroups, > but it should also show up in the documentation clearly. Ok, I believe we are *identical* w.r.t. Windows as far as oplocks go. If the vendor says disable oplocks with Windows, disable them with Samba also. If not, leave them in place. > - Office file locking workaround(s) were not immediately obvious > > Buried in the nice (but large) Official Samba Reference and HOWTO is a > fix for sharing Word and Excel files through Samba, which involves using > the sticky bit for group permissions. While the fix was adequate and > works well, it should have been I think a little more prominently > displayed in the documentation. Can you point that out to me. We've done more work on ACL compatibility with 3.0.28a and I believe that fix may not now be needed. > - What? You want me to unlock that file? > > We have had recurring instances where a workstation on the network has > seized a DBF file and held onto it, not allowing any other workstation or > server to perform writes to the file. This locking issue shows up in > random intervals and always requires that we have the person quit the > program we are using and log back in. It is not an application issue > that we can determine - the rest of the system continues to funciton, it > just prevents one of our servers (or anyone else) from locking the file. Sounds like a bug to me. Not sure where, client app or Samba. Need more info on this. > - Speaking of which - just WHO does have that file lock? > > For some reason, using the computer management tool in a windows > workstation shows stale information. In our past arrangement, we were > able to determine who would have the locked file by simply connecting the > tool to the server, and sorting on the number of locks present; the tool > would show the data file with a lock count greater than zero. Apparently > this doesn't fly when connecting to the Samba server - it shows files > open, but the lock count is for ALL locks (including reads) and not just > write locks. This seems like a Samba dificiency with that tool. You should be able to get that info by running smbstatus on the
[Samba] Looking for a set of definitive answers (long)
Question: We recently moved to a Samba-based file server, which holds mission- critical data on it (.dbf files used by our Accounting software, etc.) The goal was to create a file server that had excellent performance while providing Volume Management, but we felt that something like Veritas was overkill for our needs. Design Goals: - Redundant Hardware - Manual Failover (this was an acceptable solution) - Very large storage capacity (minimum 1 Terabyte) - Better than 100Mbyte/sec throughput - Volume Management, Journaled Filesystem - Drop-In Replacement for aging Win2k file server - Use existing admin tools to avoid retraining The proposed solution was a Samba file server running on a pair of redundant servers, with one connected to an eSATA raid box, with LVM and Ext3 providing volume management and journaling. Our transition was a bit rough, but in the end it has been very stable and fast. We have been really pleased with the performance of the hardware/software combo, seeing sustained throughput of about 250Mbyte/sec with peaks as high as 300Mbyte/sec. But along the way, we encountered some oddities, and I have some remaining questions. First, the oddities (long-time Samba devs and admins, take this with a grain of salt, when I say oddity I mean it from the perspective of an experienced Windows administrator): - 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. - 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). - To oplock or not to oplock: that is the question The documentation is not entirely clear about when you should and shouldn't use oplocks on shared files. It would have been much simplier (IMHO) to simply say "use your best judgement, BUT if you are using shared data files like Access or Excel or DBF's, you will want to disable them or you'll have problems!". Yes those words show up on newsgroups, but it should also show up in the documentation clearly. - Office file locking workaround(s) were not immediately obvious Buried in the nice (but large) Official Samba Reference and HOWTO is a fix for sharing Word and Excel files through Samba, which involves using the sticky bit for group permissions. While the fix was adequate and works well, it should have been I think a little more prominently displayed in the documentation. - What? You want me to unlock that file? We have had recurring instances where a workstation on the network has seized a DBF file and held onto it, not allowing any other workstation or server to perform writes to the file. This locking issue shows up in random intervals and always requires that we have the person quit the program we are using and log back in. It is not an application issue that we can determine - the rest of the system continues to funciton, it just prevents one of our servers (or anyone else) from locking the file. - Speaking of which - just WHO does have that file lock? For some reason, using the computer management tool in a windows workstation sh
