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

This is a discussion on [Samba] Looking for a set of definitive answers (long) - Samba ; 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, ...

+ Reply to Thread
Results 1 to 16 of 16

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

  1. [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 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.

    - You sure you still have that file open? It says you don't even have it!

    The computer management tool also has an issue with data appearing to be
    stale. Workstations that have been powered down still show a file open.
    Or in some cases, the workstation is working with the file, but no file
    handle appears in the tool! This was (and still is) a major issue for
    our staff, and as a result of this they have learned not to trust this
    once-reliable tool, because from their point of view, it lies to them. I
    have had to come up with some work-arounds and while they do work they
    are suboptimal in their eyes.

    Now, the remaining question(s):

    - 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?

    - Is there a way to get the Computer Mangement tool to not "lie" to us
    about the state of file handles and locks? It would be a godsend to not
    have to watch everyone roll their eyes because the "expected" way of
    locating file issues simply doesn't work for them. This is an ongoing
    issue and I can't really provide a satisfactory answer - even SWAT
    appears to have this issue as well! I have resorted to shell scripting
    to provide us with the answers we need but this is hardly a long-term
    solution. Is there some magic setting I need to flip in the registry for
    our Windows XP clients to make this issue just go away? Is it related to
    protocol changes in the newer versions of the Windows redirectors? Just
    why does this happen?

    A parting thought as well:

    It would have been nice to have had a reasonably generic template or
    example somewhere that pointed this out, instead of wasting an incredible
    amount of time (a month!) reading many many many pages of documentation,
    sometimes scattered into different chapters, as well as contacting the
    vendor twice with over a half-dozen messages. I would think that a
    simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
    a generic looking setup would have resolved many of these issues, by
    having the appropriate settings and comments already in the file while
    pointing out what parts of the template needed to be changed. Everyone
    that I have talked to outside of my work looks at Samba as a drop-in
    replacement for existing Win2k(3) file servers, and a template with
    settings that come closest to emulating that same behavior would go a
    long ways towards adoption. I'm not trying to be overly critical, but
    rather, I'm trying to point out a missing part of the software package
    that I think administrators would like to have, especially as more and
    more companies start to operate in mixed environments.

    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  2. Re: [Samba] Looking for a set of definitive answers (long)

    On Wed, May 21, 2008 at 06:47:52PM +0000, 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 box.

    > - You sure you still have that file open? It says you don't even have it!
    >
    > The computer management tool also has an issue with data appearing to be
    > stale. Workstations that have been powered down still show a file open.
    > Or in some cases, the workstation is working with the file, but no file
    > handle appears in the tool! This was (and still is) a major issue for
    > our staff, and as a result of this they have learned not to trust this
    > once-reliable tool, because from their point of view, it lies to them. I
    > have had to come up with some work-arounds and while they do work they
    > are suboptimal in their eyes.


    Same as above. smbstatus should give you this info.

    > Now, the remaining question(s):
    >
    > - 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?


    It is safe to use tdbbackup on a live system. The vendor is
    mistaken.

    > - Is there a way to get the Computer Mangement tool to not "lie" to us
    > about the state of file handles and locks? It would be a godsend to not
    > have to watch everyone roll their eyes because the "expected" way of
    > locating file issues simply doesn't work for them. This is an ongoing
    > issue and I can't really provide a satisfactory answer - even SWAT
    > appears to have this issue as well! I have resorted to shell scripting
    > to provide us with the answers we need but this is hardly a long-term
    > solution. Is there some magic setting I need to flip in the registry for
    > our Windows XP clients to make this issue just go away? Is it related to
    > protocol changes in the newer versions of the Windows redirectors? Just
    > why does this happen?


    Needs more work in Samba on supporting the Computer management
    tool. Currently smbstatus works better for this.

    > A parting thought as well:
    >
    > It would have been nice to have had a reasonably generic template or
    > example somewhere that pointed this out, instead of wasting an incredible
    > amount of time (a month!) reading many many many pages of documentation,
    > sometimes scattered into different chapters, as well as contacting the
    > vendor twice with over a half-dozen messages. I would think that a
    > simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
    > a generic looking setup would have resolved many of these issues, by
    > having the appropriate settings and comments already in the file while
    > pointing out what parts of the template needed to be changed. Everyone
    > that I have talked to outside of my work looks at Samba as a drop-in
    > replacement for existing Win2k(3) file servers, and a template with
    > settings that come closest to emulating that same behavior would go a
    > long ways towards adoption. I'm not trying to be overly critical, but
    > rather, I'm trying to point out a missing part of the software package
    > that I think administrators would like to have, especially as more and
    > more companies start to operate in mixed environments.


    Yep, this is true. We depend on the Linux vendors to do this as
    we don't have the resources (or more accurately haven't spent
    the resources we have) on doing this. Sometimes they do a good
    job, sometimes not. This is why server appliance vendors often
    are a better choice than a full blown Linux solution, as they
    sell a pre-set up solution.

    Thanks for your thoughts !

    Jeremy.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  3. 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 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.


    Please write this up in a step-by-step form that can be added to one of the
    books.


    > - 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.


    You can also add to the smb.conf share definition stanza the following
    parameters that are documented in the smb.conf man page:

    inherit owner
    inherit acls
    inherit permissions

    Did you consider these? If so, what problems did they cause you?

    > 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).


    OK - I understand the problem. What did you do to bring about better
    documentation? Did you consider contributing some guidance documentation and
    then circulation to get positive feedback from other Samba users?

    Better documentation is always welcome. Contributions are continually sought.


    > - 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.


    I have not seen a single installation where DBF files and MDB file sharing
    works acceptably with more than 3-5 concurrent users. It makes not
    difference if the files are served off Windows Server 2003 or off a Samba
    server. Oplocks slow things down and have side-effects. What-ever problems
    you have with Windows servers will follow you to the Samba server also.

    Best advice is do not use file sharing for multiple concurrent access database
    files. Instead, use a SQL backend database.


    > - 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.


    Where in the book would you prefer to see this documented? What changes would
    you make to the documentation to make this more prominent and more readily
    capble of being found?


    > - 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.


    This is a client-side caching issue. Samba does not know that the file has
    been released until the client notifies Samba that it has released the file.
    Windows clients can go down without ever releasing the file. There are
    Microsoft KB articles on how to disable client-side caching. Should this be
    more vigorously documented in the HOWTO? If so, where should it be documented
    in TOSHARGs?


    > - 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.


    What tool are you using to explore this?


    > - You sure you still have that file open? It says you don't even have it!
    >
    > The computer management tool also has an issue with data appearing to be
    > stale. Workstations that have been powered down still show a file open.


    See comment to previous question about this.

    > Or in some cases, the workstation is working with the file, but no file
    > handle appears in the tool! This was (and still is) a major issue for
    > our staff, and as a result of this they have learned not to trust this
    > once-reliable tool, because from their point of view, it lies to them. I
    > have had to come up with some work-arounds and while they do work they
    > are suboptimal in their eyes.


    This sounds like a bug. How can we reproduce this?


    > Now, the remaining question(s):
    >
    > - 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.


    Unless I am sadly mistaken, the TOSHARG docs are correct. You really should
    use tdbbackup on a regular basis in every large installation.

    > 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).


    The vendor is mistaken. Please ask the vendor to speak with one of the Samba
    developers.

    > 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?


    LDAP is the way to go for IDMAP sharing across domain member servers. The tdb
    files really should not be replicated across servers.

    > - Is there a way to get the Computer Mangement tool to not "lie" to us
    > about the state of file handles and locks? It would be a godsend to not
    > have to watch everyone roll their eyes because the "expected" way of
    > locating file issues simply doesn't work for them. This is an ongoing
    > issue and I can't really provide a satisfactory answer - even SWAT
    > appears to have this issue as well!


    SWAT is not being actively maintained.

    > I have resorted to shell scripting
    > to provide us with the answers we need but this is hardly a long-term
    > solution. Is there some magic setting I need to flip in the registry for
    > our Windows XP clients to make this issue just go away? Is it related to
    > protocol changes in the newer versions of the Windows redirectors? Just
    > why does this happen?


    So far as I am aware Samba fully matches the behavior of Windows server 2003.
    Samba can not fix client-sied issues. You need to set your client registry
    correctly to stop client-side caching for MDB and DBF files. I do believe
    that is documented somewhere in TOSHARG.


    > A parting thought as well:
    >
    > It would have been nice to have had a reasonably generic template or
    > example somewhere that pointed this out, instead of wasting an incredible
    > amount of time (a month!) reading many many many pages of documentation,
    > sometimes scattered into different chapters, as well as contacting the
    > vendor twice with over a half-dozen messages. I would think that a
    > simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
    > a generic looking setup would have resolved many of these issues, by


    Where would you search for this information? Which chapter? Which book? How
    should it be documented? Are you willing to write this up in a usable form?

    > having the appropriate settings and comments already in the file while
    > pointing out what parts of the template needed to be changed. Everyone
    > that I have talked to outside of my work looks at Samba as a drop-in
    > replacement for existing Win2k(3) file servers,


    Everyone can be mistaken, fortunately not everone is always mistaken.

    > and a template with
    > settings that come closest to emulating that same behavior would go a
    > long ways towards adoption. I'm not trying to be overly critical, but
    > rather, I'm trying to point out a missing part of the software package
    > that I think administrators would like to have, especially as more and
    > more companies start to operate in mixed environments.


    I want to commend you on your email. You comments are due criticism. Your
    assistance to close out your concerns is most appreciated.

    Cheers,
    John T.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  4. Re: [Samba] Looking for a set of definitive answers (long)

    On Wed, 21 May 2008 18:47:52 +0000 (UTC)
    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


    [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

  5. [Samba] Re: Looking for a set of definitive answers (long)

    On Wed, 21 May 2008 12:33:34 -0700, Jeremy Allison wrote:

    > On Wed, May 21, 2008 at 06:47:52PM +0000, 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.)
    >> [big snip]


    >> 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.


    I think it will.

    >
    >> - To oplock or not to oplock: that is the question
    >>
    >> [snip]

    >
    > 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.


    I was in a hurry to write all of this (as I am always pressed for time)
    but what I was trying to convey is that the documentation could probably
    be a bit clearer on this. Yes, I will be happy to contribute some
    documentation to this specific issue.
    >
    >> - 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. [snip]

    >
    > Can you point that out to me.


    Sure. "The Official Samba-3 HOWTO and Reference Guide", Second Edition,
    (c) 2006 John H. Terpstra, printed by Prentice-Hall, Professional
    Technical Reference. Turn to page 264, last 4 paragraphs on the page
    (including 1 inset caption). Heading is 15.6.3, "MS Word with Samba
    Changes Owner of File". The description of what to do provided a
    significant fix for us.

    > We've done more work on ACL compatibility
    > with 3.0.28a and I believe that fix may not now be needed.


    The vendor's version is samba-3.0.25b-1.el5_1.4. I can't mention the
    vendor but I think you could probably guess it by looking at that version
    number.

    >> - 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. [snip]

    >
    > Sounds like a bug to me. Not sure where, client app or Samba. Need more
    > info on this.


    The application is ACCPAC Pro Series 7.2 (now relabeled Sage Pro
    Series). It is written in Visual FoxPro 8, and uses VFP DBF, CDX, DBC,
    VCX, etc. files, almost all of which are really just mutant dBase tables,
    so any record or file locking semantics that apply to DBF files will
    apply to those files as well.

    I used to see this behavior years ago with Win95 workstations talking
    with a Win2k file server. The issue disappeared when we migrated the
    workstations to Win2k. It might not be so much a Samba bug as it is an
    issue with the settings for the workstation redirectors.

    >
    >> - 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. [snip]

    >
    > This seems like a Samba dificiency with that tool. You should be able to
    > get that info by running smbstatus on the Samba box.


    There's the rub. The existing staff expect to use the in-place GUI
    toolset and have no interest in learning command line tools (including
    the department head). Yeah, I know, nothing you can do about that
    directly, but indirectly, it might be worth looking into making minor
    tweaks to function with the Computer Management snap-in.

    You can test this easily by openning several files (Excel, Word, Access,
    doesn't matter) at several workstations, start making changes but *don't
    save them*...let the workstations and server sit for a bit...then open
    the Comp. Mgmt. snap-in, right-click on the top of tree, select "Connect
    to another computer...", place the server name in the dialog that appears
    and click on [OK]. Navigate to Computer Management -> System Tools ->
    Shared Folders -> Open Files. You'll see a list of files that are
    "open". Note that after a long period of time - say, a few days - that
    the file you openned *doesn't appear in the list* after a refresh (press
    F5 to refresh). Nothing wrong with that, as I understand that the client
    or server may close the connection - but if you do this same operation on
    a "stock" Windows box, the file handle is persisent for as long as you
    have the file open and both the server and workstation running. In short
    - the file semantics being reported are different between a Samba server
    and a Windows server when using this tool. If this is a design decision,
    you might want to have a small blurb in the docs someplace about how
    those semantics differ, so administrators don't feel like they're going
    insane when they can't figure out why a file is still in use but it isn't
    reported by the snap-in.

    Another way to look at this is to open a shell and compare the output of
    lsof against smbstatus - you'll see that, over time, there are occasional
    discrepencies between the two as far as what files are open, etc.

    Using smbstatus was (unfortunately) not effective for us - it showed
    different results from the snap-in I mentioned above, but like the snap-
    in, it would have discrepencies between what lsof reports and what it
    reports. We would also see "no one has that file open" but when we try
    to obtain an exclusive lock on the DBF, it would report that it is in use
    by someone (and indeed, it was). The final solution in locating a locked
    file was to place this in a shell script named 'find-lock':

    lsof | grep 'vp' | grep 'u[wW] '

    As crude as it is, it works. The "vp" refers to a fixed pathname that is
    unique to our installation, so we can narrow down the number of files to
    just those files that may contain DBF data. The grep looks for write
    locks, either at a table (file) level or a record level. It has been
    100% accurate in the 8 times that we have had to use it.

    >
    >> - You sure you still have that file open? It says you don't even have
    >> it!
    >>
    >> The computer management tool also has an issue with data appearing to
    >> be stale. [snip]

    >
    > Same as above. smbstatus should give you this info.


    Addressed above.

    >
    >> Now, the remaining question(s):
    >>
    >> - The vendor initially set up our authentication via tdb files and
    >> Winbind. [snip]
    >> 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?

    >
    > It is safe to use tdbbackup on a live system. The vendor is mistaken.


    THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU....

    That single reply was worth its weight in gold. I can now sleep a little
    better at night.

    >> - Is there a way to get the Computer Mangement tool to not "lie" to us
    >> about the state of file handles and locks? [snip]

    >
    > Needs more work in Samba on supporting the Computer management tool.
    > Currently smbstatus works better for this.


    Also addressed above.

    >
    >> A parting thought as well:
    >>
    >> It would have been nice to have had a reasonably generic template or
    >> example somewhere that pointed this out... [snipped long frustration]

    >
    > Yep, this is true. We depend on the Linux vendors to do this as we don't
    > have the resources (or more accurately haven't spent the resources we
    > have) on doing this. Sometimes they do a good job, sometimes not. This
    > is why server appliance vendors often are a better choice than a full
    > blown Linux solution, as they sell a pre-set up solution.


    Long story short, it wasn't on the radar due to other issues - but I'll
    keep that in mind.

    >
    > Thanks for your thoughts !


    Thanks for the reply!

    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  6. [Samba] Re: Looking for a set of definitive answers (long)

    On Wed, 21 May 2008 15:31:48 -0500, John H Terpstra wrote:

    > 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.


    More than happy to as soon as I can find the time.
    '
    >
    > 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.


    Understood. I am using it as a tech reference.

    > 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?


    I didn't even know it existed. The majority of web queries resulted in
    the online version of TOSHARG being displayed. Thanks for pointing that
    out, I'll look for it.

    > Are you offering to improve its value and utility by contributing your
    > experiences and recommendations?


    Yes, as time permits.

    >
    > On Wednesday 21 May 2008 01:47:52 pm Avery Payne wrote:
    >> Question:
    >>
    >> 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.


    I think we're 99.9% there, it's that 0.1% that's holding up the works.
    Overall, everyone is pleased.

    > [lots 'o stuff snipped]
    >> 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.


    The solution is that there are nightly backups of all the tdb's to a
    known LVM volume. The idea is that in the even of manual failover, the
    volume would be mounted, the tdb's copied into place, some minor settings
    changed, and the service started.

    Originally I was aiming for a "clustered" approach but it appears that
    the software (both the OS and Samba) were not ready for this - yet Samba
    4 may still surprise me.

    >
    > I would have used a RAID5 array in each server with rsync to synchronize
    > from the master to the slave.


    There is no master-slave, the other machine is a cold-standby solution.
    The RAID 10 array contains 16 drives on a eSATA box that has redundant
    power, redundant connects, etc. A manual failover was chosen by
    mangement due to cost and software constraints. The downtime involved
    was deemed acceptable - 5 to 10 minutes. Downtime exceeding 15 minutes
    however would start creeping costs into the red.

    >
    >> 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.


    3 months. This is an epic story for another time.

    >
    >> - File permissions do not behave as expected (from the viewpoint of
    >> other staff working with the server).
    >>
    >> [snip]

    >
    > 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.


    Point appreciated. As a Linux admin (since '98) and a Windows NT admin
    (since '97), I can appreciate the semantical differences between the two,
    and the efforts involved by the Samba devs to make things "work". I did
    read those sections (repeatedly). Sometimes it's easy to miss things
    when the world is at your door screaming for blood - especially when it's
    your blood.

    As for the admin training side, my co-worker is an MCSE coming from 20
    years of VAX/PDP experience, and the department head (my direct boss) is
    an OS X fan who uses 10.5 on a daily basis. Which makes for interesting
    conversations between us all.

    >
    > Jeremy's notes about the VFS modular work aimed at providing better
    > Windows ACLs emulation may provide the solution you are looking for.


    I have read about some of the VFS features and will be using the audit
    feature in the near future. However, some of what I face may be a
    versioning issue due to the vendor (or not).

    >
    >> 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?


    Q: Why can't I delete these entries inside of the directory/file property
    pane? They keep reappearing no matter what I do. (the question phrased
    as given to me by both my coworker and my boss)

    The issue is that the frame of reference - "this is how we set file
    permissions and this is the expected behavior of the vendor-provided GUI
    tool" - is somewhat different from the material that is being presented.
    I have had to do alot of verbal footwork in translating things. Perhaps
    I can help here with some new material...

    > Where and how did you look?


    "The Official Samba-3 HOWTO and Reference Guide", Second Edition,
    (c) 2006 John H. Terpstra, printed by Prentice-Hall, Professional
    Technical Reference.

    The quickest solution to the issue was found with deductive reasoning
    coupled with emprical experimentation. Good old-fashioned 'sit down and
    work it out'.

    > Did you use a hard-copy of the book?


    Yes. See above book reference.

    > Search online in the HTML web
    > pages?


    Yes, both through site searches at samba.org and through google.
    Unfortunately, they ended up being web versions of the book.

    > Or did you download the PDF of the book and use the hotlinked
    > pages in the subject and topic indexes?


    Yes.

    >
    >> [snip]
    >> We've found that this method has the closest behavior to a
    >> "real" Windows server and has satisfied everyone.

    >
    > Please write this up in a step-by-step form that can be added to one of
    > the books.


    More than happy to, as time permits.

    >
    >
    >> - Permissions don't propigate through the filesystem.
    >>
    >> [dumb issue that I could have avoided snipped]

    >
    > You can also add to the smb.conf share definition stanza the following
    > parameters that are documented in the smb.conf man page:
    >
    > inherit owner
    > inherit acls
    > inherit permissions


    Thanks! The reason they were not used initially is that the initial
    permissions model didn't account for that (because I didn't know the
    settings were there), and on top of that, it changed during the
    transition. Some of the filesystem is using the original model - where
    domain groups are mapped to a GID on the linux box and the directory/
    files are then updated with that GID - while other directories are
    following the ACL approach. Throw in some complete confusion by the
    vendor's muddled guidence, and it gets messy. As I have time permitting,
    the entire filesystem will be migrated to the ACL approach.

    >
    > Did you consider these?


    No (see above). It will be rememdied. Lesson: when in doubt, stick with
    your gut, because the vendor usually doesn't get it right on the first
    try.

    > If so, what problems did they cause you?


    N/A (see above)

    >
    >> 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).

    >
    > OK - I understand the problem. What did you do to bring about better
    > documentation?


    I repeatedly hit myself on the head with a baseball bat. Just kidding.

    The documentation was created in-house at my employer's expense. I will
    attempt to re-write the docs I created on my own time and provide them to
    you later.

    > Did you consider contributing some guidance
    > documentation and then circulation to get positive feedback from other
    > Samba users?


    Yes, but the time factor involved was prohibitive. Hard to do the right
    thing when you're holding off end-users with a pointy stick. See my
    other post to Jeremy re: users screaming for blood. That, and it's hard
    to think straight after working a 38 hour shift with no sleep, no food,
    no breaks, and no rest.

    >
    > Better documentation is always welcome. Contributions are continually
    > sought.


    More on that later. I have some ideas that I think would be worthwhile,
    and I'm willing to type them up.

    >> - 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. [frustrations snipped]

    >
    > I have not seen a single installation where DBF files and MDB file
    > sharing works acceptably with more than 3-5 concurrent users.


    In our prior version of the software we had 50 workstations, of which
    half were concurrently active, updating/reading DBF files every day.
    Locking is kept to a minimum, which contributes to a very low latency.
    The general "gut feel" we have here is that the limit of our system is
    probably around 50 concurrent users; on busier days with more than 30
    workstations active, the system started to visibly slow, although
    performance degraded gracefully. The setup (at the time) was a Win2k
    Server with 50 Win2k Workstations on switched 100BaseT, with gigabit
    going into the server.

    >
    > Best advice is do not use file sharing for multiple concurrent access
    > database files. Instead, use a SQL backend database.


    The ERP package in use allows us to do so for a very prohibitive price.
    It would actually be cheaper to employ me for an entire year to develop
    an object wrapper to intercept all calls to the DB API and send them to a
    PostgreSQL or MySQL backend, working full time on this project and doing
    none of my other duties (networking, sysadmin, security, email services,
    data warehouse, end-user support, customization of the accounting
    package, etc.), while struggling to emulate all of the features with only
    the API interface as a document to guide me (there is no source
    available). Of course, that isn't going to happen.

    >
    >
    >> - Office file locking workaround(s) were not immediately obvious
    >>
    >> [snip]

    >
    > Where in the book would you prefer to see this documented? What changes
    > would you make to the documentation to make this more prominent and more
    > readily capble of being found?


    The largest issue encountered revolved around locking semantics and how
    the system would behave. This I will fully address later when I write up
    my docs and send them to you.

    >> - 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.

    >
    > This is a client-side caching issue. Samba does not know that the file
    > has been released until the client notifies Samba that it has released
    > the file. Windows clients can go down without ever releasing the file.
    > There are Microsoft KB articles on how to disable client-side caching.
    > Should this be more vigorously documented in the HOWTO?


    Yes, although I would prefer the term "slightly expanded article".

    > If so, where should it be documented in TOSHARGs?


    The viewpoint comes from a small-to-medium sized LAN installation, using
    shared-file databases (dBase, FoxPro, Paradox, Access). This may not be
    very common in larger installations, but I can attest (from personal
    experience) that it is frequently used in smaller setups.

    I think the real issue is that there is a juncture between file locking
    and file permissions that are critical to having those environments work
    correctly. A small paragraph about shared-file databases would probably
    go a long ways towards providing clarity to the implementor as to how
    things will work, etc. Again, I'll try to get something to you later.

    >> - Speaking of which - just WHO does have that file lock?
    >>
    >> [snip]

    >
    > What tool are you using to explore this?


    Computer Management Snap-In.

    >
    >
    >> - You sure you still have that file open? It says you don't even have
    >> it!
    >>
    >> The computer management tool also has an issue with data appearing to
    >> be stale. Workstations that have been powered down still show a file
    >> open.

    >
    > See comment to previous question about this.
    >
    >> Or in some cases, the workstation is working with the file, but no file
    >> handle appears in the tool! [snip]

    >
    > This sounds like a bug. How can we reproduce this?


    See my posting to Jeremy on this. I'll try to develop a specific test,
    but the description I gave is the best I can do for now until I can
    catagorize the bug further.

    >
    >
    >> Now, the remaining question(s):
    >>
    >> - 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.

    >
    > Unless I am sadly mistaken, the TOSHARG docs are correct. You really
    > should use tdbbackup on a regular basis in every large installation.


    Jeremy has confirmed this. Thanks for the 2nd confirmation. And I am
    backing up all tdb's daily to an LVM volume on the RAID array, so when
    the 2nd system goes live, I can simply restore them with tdbbackup.



    >
    >> [snip]

    > You need to set your client
    > registry correctly to stop client-side caching for MDB and DBF files. I
    > do believe that is documented somewhere in TOSHARG.


    I am using both global and share-level "veto oplocks" settings, with a
    very detailed match string.

    >
    >
    >> A parting thought as well:
    >>
    >> It would have been nice to have had a reasonably generic template or
    >> example somewhere that pointed this out [snip]

    >
    > Where would you search for this information? Which chapter? Which book?
    > How should it be documented? Are you willing to write this up in a
    > usable form?


    1) it should be part of a section on implementing replacement file
    services for Win2k(3) boxen.
    2) undetermined. I will have to look at that. I am already almost over
    my time limits on this reply today (forgoing lunch to reply).
    3) again, undetermined.
    4) Yes.


    > Everyone can be mistaken, fortunately not everone is always mistaken.




    Part of my job is to pull magic rabbits out of the hat. I fear the day
    when I reach in the hat and come up empty-handed.


    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  7. [Samba] Re: Looking for a set of definitive answers (long)

    On Thu, 22 May 2008 10:59:08 +0200, Chris Osicki wrote:

    > On Wed, 21 May 2008 18:47:52 +0000 (UTC) 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)

    > [snip]


    > 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.

    They "float on a liferaft" that is an LVM partition. The tdb's are
    backed up nightly and placed in the partition. Should the server fail,
    the tdb's are restored and the smb.conf modified...


    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  8. Re: [Samba] Re: Looking for a set of definitive answers (long)

    On Thursday 22 May 2008 02:48:14 pm Avery Payne wrote:
    > On Wed, 21 May 2008 15:31:48 -0500, John H Terpstra wrote:
    > > 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.

    >
    > More than happy to as soon as I can find the time.


    Good. Thanks.

    >
    > > 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.

    >
    > Understood. I am using it as a tech reference.


    Good.

    > > 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?

    >
    > I didn't even know it existed. The majority of web queries resulted in
    > the online version of TOSHARG being displayed. Thanks for pointing that
    > out, I'll look for it.


    Please check it out and let me know what is missing. Also, since you did not
    know it exists, what should we do to make it more prominent? Is it worth
    making it more prominent?

    You can download it from:
    http://www.samba.org/samba/docs/Samba3-ByExample.pdf

    > > Are you offering to improve its value and utility by contributing your
    > > experiences and recommendations?

    >
    > Yes, as time permits.


    Great. This sort of contribution is necessary.

    > ...
    > More on that later. I have some ideas that I think would be worthwhile,
    > and I'm willing to type them up.
    >
    > >> - 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. [frustrations snipped]

    > >
    > > I have not seen a single installation where DBF files and MDB file
    > > sharing works acceptably with more than 3-5 concurrent users.

    >
    > In our prior version of the software we had 50 workstations, of which
    > half were concurrently active, updating/reading DBF files every day.
    > Locking is kept to a minimum, which contributes to a very low latency.
    > The general "gut feel" we have here is that the limit of our system is
    > probably around 50 concurrent users; on busier days with more than 30
    > workstations active, the system started to visibly slow, although
    > performance degraded gracefully. The setup (at the time) was a Win2k
    > Server with 50 Win2k Workstations on switched 100BaseT, with gigabit
    > going into the server.


    DBF files are a special case. While the client can cache any file, DBF's have
    an internal locking method. A DBF application will set a record lock flag and
    is responsible for resetting it on completion of write. If the client does
    not flush its cache this info can get lost with the result that the record
    remains locked. There are some apps that will scan the DBF file for stale
    locks and reset them. Corruption of DBFs is usually not as big a problem as
    with MDB files.

    > > Best advice is do not use file sharing for multiple concurrent access
    > > database files. Instead, use a SQL backend database.

    >
    > The ERP package in use allows us to do so for a very prohibitive price.
    > It would actually be cheaper to employ me for an entire year to develop
    > an object wrapper to intercept all calls to the DB API and send them to a
    > PostgreSQL or MySQL backend, working full time on this project and doing
    > none of my other duties (networking, sysadmin, security, email services,
    > data warehouse, end-user support, customization of the accounting
    > package, etc.), while struggling to emulate all of the features with only
    > the API interface as a document to guide me (there is no source
    > available). Of course, that isn't going to happen.
    >
    > >> - Office file locking workaround(s) were not immediately obvious
    > >>
    > >> [snip]

    > >
    > > Where in the book would you prefer to see this documented? What changes
    > > would you make to the documentation to make this more prominent and more
    > > readily capble of being found?

    >
    > The largest issue encountered revolved around locking semantics and how
    > the system would behave. This I will fully address later when I write up
    > my docs and send them to you.


    My purpose in asking is to find a better way to present the info we have so
    that people will more rapidly find the answer. How can we do that?

    > >> - 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.

    > >
    > > This is a client-side caching issue. Samba does not know that the file
    > > has been released until the client notifies Samba that it has released
    > > the file. Windows clients can go down without ever releasing the file.
    > > There are Microsoft KB articles on how to disable client-side caching.
    > > Should this be more vigorously documented in the HOWTO?

    >
    > Yes, although I would prefer the term "slightly expanded article".
    >
    > > If so, where should it be documented in TOSHARGs?

    >
    > The viewpoint comes from a small-to-medium sized LAN installation, using
    > shared-file databases (dBase, FoxPro, Paradox, Access). This may not be
    > very common in larger installations, but I can attest (from personal
    > experience) that it is frequently used in smaller setups.
    >
    > I think the real issue is that there is a juncture between file locking
    > and file permissions that are critical to having those environments work
    > correctly. A small paragraph about shared-file databases would probably
    > go a long ways towards providing clarity to the implementor as to how
    > things will work, etc. Again, I'll try to get something to you later.


    I do believe that is in the HOWTO somewhere. Bear in mind that locking and
    client-side caching are orthogonal issues.

    > >> - Speaking of which - just WHO does have that file lock?
    > >>
    > >> [snip]

    > >
    > > What tool are you using to explore this?

    >
    > Computer Management Snap-In.


    OK - understood.

    >...
    >> > You need to set your client

    > > registry correctly to stop client-side caching for MDB and DBF files. I
    > > do believe that is documented somewhere in TOSHARG.

    >
    > I am using both global and share-level "veto oplocks" settings, with a
    > very detailed match string.


    This does not stop a windows client from doing client-side cacheing. The only
    way to do that is to change the registry settings on the client.

    > >> A parting thought as well:
    > >>
    > >> It would have been nice to have had a reasonably generic template or
    > >> example somewhere that pointed this out [snip]

    > >
    > > Where would you search for this information? Which chapter? Which book?
    > > How should it be documented? Are you willing to write this up in a
    > > usable form?

    >
    > 1) it should be part of a section on implementing replacement file
    > services for Win2k(3) boxen.


    Really? Client-side caching is done by Windows 95 and later, and all Windows
    NT-based systems. I'm not convinced that title will do.

    > 2) undetermined. I will have to look at that. I am already almost over
    > my time limits on this reply today (forgoing lunch to reply).


    Thanks for answering.

    > 3) again, undetermined.
    > 4) Yes.


    Cheers,
    John T.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  9. Re: [Samba] Re: Looking for a set of definitive answers (long)

    On Thu, May 22, 2008 at 06:51:39PM +0000, Avery Payne wrote:

    > There's the rub. The existing staff expect to use the in-place GUI
    > toolset and have no interest in learning command line tools (including
    > the department head). Yeah, I know, nothing you can do about that
    > directly, but indirectly, it might be worth looking into making minor
    > tweaks to function with the Computer Management snap-in.


    I've just fixed a couple of bugs with the Computer Management
    plug in operating against Samba for 3.2 release.

    > You can test this easily by openning several files (Excel, Word, Access,
    > doesn't matter) at several workstations, start making changes but *don't
    > save them*...let the workstations and server sit for a bit...then open
    > the Comp. Mgmt. snap-in, right-click on the top of tree, select "Connect
    > to another computer...", place the server name in the dialog that appears
    > and click on [OK]. Navigate to Computer Management -> System Tools ->
    > Shared Folders -> Open Files. You'll see a list of files that are
    > "open". Note that after a long period of time - say, a few days - that
    > the file you openned *doesn't appear in the list* after a refresh (press
    > F5 to refresh). Nothing wrong with that, as I understand that the client
    > or server may close the connection - but if you do this same operation on
    > a "stock" Windows box, the file handle is persisent for as long as you
    > have the file open and both the server and workstation running. In short
    > - the file semantics being reported are different between a Samba server
    > and a Windows server when using this tool. If this is a design decision,
    > you might want to have a small blurb in the docs someplace about how
    > those semantics differ, so administrators don't feel like they're going
    > insane when they can't figure out why a file is still in use but it isn't
    > reported by the snap-in.


    Now you've raised this to my attention I'm going to make sure
    that the MMC computer management works 100% when operating against
    a 3.2 server (it's easy to do for 3.2 as Guenther and Jerry
    already did the work to convert to IDL and I just need to
    fix bugs in their work :-).

    Cheers and thanks for the heads up on the problem,

    Jeremy.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  10. Re: [Samba] Looking for a set of definitive answers (long)

    On Thu, May 22, 2008 at 4:59 AM, Chris Osicki
    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

  11. 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
    > 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

  12. Re: [Samba] Looking for a set of definitive answers (long)

    On Fri, May 23, 2008 at 5:59 PM, Jeremy Allison 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
    >> 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

  13. 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

  14. [Samba] Airing Dirty Laundry

    On Sat, 24 May 2008 01:00:31 +0200, Udo Rader wrote:


    >
    > 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


    Please note that this has had names changed to protect the guilty and
    confuse the innocent. I have also heavily bowlderized any mention of
    vendors into formats suitable for public display. Settings have been
    left intact, and the entire shebang is of course behind a firewall so
    I have no fear in exposing networking names.

    The references can easily be inferred and for those who are not in
    the know, you can visit www.centos.org and determine for yourself what
    Prominent North American Enterprise Linux Vendor refers to.

    Please forgive the cut-n-paste verbosity but at the time there was
    considerable pressure and emphasis on documenting why each setting was
    used, why the GUI wasn't used (which was a sore point with some staff) and
    who-set-what, hence the repeated mention of GUI options not being
    available, etc. And yes, there are a few sections that "repeat" - I
    noticed that and will be cleaning that up as we head towards implementing
    recommendations. After getting my public flogging^W^W^W^Wreceiving
    constructive critism, I'll be looking forward to implementing ACL
    inheritance and other settings that are sorely missing.

    Yes, it's a mess, yes it needs some work - but that's why I'm posting it
    here, eh?


    #===================== Global Settings ===============================

    [global]

    # ----------------------- Network Related Options
    -------------------------
    #
    # workgroup = NT-Domain-Name or Workgroup-Name, eg: MIDEARTH
    #
    # server string is the equivalent of the NT Description field
    #
    # netbios name can be used to specify a server name not tied to the
    hostname
    #
    # Interfaces lets you configure Samba to use multiple interfaces
    # If you have multiple network interfaces then you can list the ones
    # you want to listen on (never omit localhost)
    #
    # Hosts Allow/Hosts Deny lets you restrict who can connect, and you can
    # specifiy it as a per share option as well
    #
    workgroup = PDX
    ; --- 2007-12-08 reset the server string to shorten its description and
    bring it in line with other porthole servers.
    ; --- This string can be set in the Prominent North American Enterprise
    Linux Vendor GUI.
    server string = %L
    netbios name = SRV2210
    interfaces = lo eth0 eth1
    ; --- 2007-12-08 added standard options that increase performance (refer
    to the Offical Samba 3.2 documentation
    ; --- at samba.org). DO NOT REMOVE THE SO_RCVBUF SETTING OR CHANGE IT,
    IT IS PART OF A FIX TO THE ISSUE SURROUNDING
    ; --- DELAYED WRITES FOR MACROSQUISH PORTHOLE CLIENTS. YOU HAVE BEEN
    WARNED!
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY
    SO_RCVBUF=8192 SO_SNDBUF=16738

    ; --- 2008-01-16 added "keepalive" option
    keepalive = 30

    ; --- 2008-01-22 added "deadtime" option; zero means it will never
    disconnect
    ; --- a client.
    deadtime = 0
    getwd cache = yes
    # --------------------------- Logging Options
    -----------------------------
    #
    # Log File let you specify where to put logs and how to split them up.
    #
    # Max Log Size let you specify the max size log files should reach

    log file = /var/log/samba.log

    # logs split per machine
    ; log file = /var/log/samba/%m.log

    ; Level 0 = ???
    ; Level 1 = Share Access recorded
    ; Level 2 = File Access recorded
    ; Level 3 = File Locking
    ; Level 4 = High-level SMB protocol actvity
    log level = 1
    # max 50KB per log file, then rotate
    ; max log size = 50

    # ----------------------- Security Model Options ------------------------
    #
    # Scurity can be set to user, share(deprecated) or server(deprecated)
    #
    # Backend to store user information in. New installations should
    # use either tdbsam or ldapsam. smbpasswd is available for backwards
    # compatibility. tdbsam requires no further configuration.

    security = ads
    passdb backend = tdbsam

    # ----------------------- Domain Controller Options
    ------------------------
    #
    # Security must be set to user for domain controllers
    #
    # Backend to store user information in. New installations should
    # use either tdbsam or ldapsam. smbpasswd is available for backwards
    # compatibility. tdbsam requires no further configuration.
    #
    # Domain Master specifies Samba to be the Domain Master Browser. This
    # allows Samba to collate browse lists between subnets. Don't use this
    # if you already have a MacroSquish Porthole NT domain controller doing
    this job
    #
    # Domain Logons let Samba be a domain logon server for MacroSquish
    Porthole workstations.
    #
    # Logon Scrpit let yuou specify a script to be run at login time on the
    client
    # You need to provide it in a share called NETLOGON
    #
    # Logon Path let you specify where user profiles are stored (UNC path)
    #
    # Various scripts can be used on a domain controller or stand-alone
    # machine to add or delete corresponding unix accounts
    #

    ; --- 2007-12-08 DO NOT REMOVE THIS OPTION, THIS OPTION PREVENTS THE FILE
    SERVER FROM PARTICIPATING IN
    ; --- BROWSER ELECTIONS; TURNING THE OPTION ON WILL CAUSE THE FILE SERVER
    TO BECOME A POTENTIAL HOLDER OF
    ; --- THE MASTER BROWSE LIST (IE, THE COMPUTERS LISTED IN NETWORK
    EXPLODER WILL BE PROVIDED FROM DATA COLLECTED HERE!)
    ; --- Thus, turning on the option is a BAD thing. Do not do it.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    domain master = no


    # ----------------------- Browser Control Options
    ----------------------------
    #
    # set local master to no if you don't want Samba to become a master
    # browser on your network. Otherwise the normal election rules apply
    #
    # OS Level determines the precedence of this server in master browser
    # elections. The default value should be reasonable
    #
    # Preferred Master causes Samba to force a local browser election on
    startup
    # and gives it a slightly higher chance of winning the election
    ; --- 2007-12-08 DO NOT REMOVE THIS OPTION, THIS OPTION PREVENTS THE FILE
    SERVER FROM PARTICIPATING IN
    ; --- BROWSER ELECTIONS; TURNING THE OPTION ON WILL CAUSE THE FILE SERVER
    TO BECOME A POTENTIAL HOLDER OF
    ; --- THE MASTER BROWSE LIST (IE, THE COMPUTERS LISTED IN NETWORK
    EXPLODER WILL BE PROVIDED FROM DATA COLLECTED HERE!)
    ; --- Thus, turning on the option is a BAD thing. Do not do it. Let the
    domain controllers handle this!
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    domain master = no
    local master = no
    preferred master = no
    os level = 33
    ; --- 2007-12-18 because of the enormous flood of WINs errors in the
    logs, I have added this
    ; --- to get the server to think about other avenues besides wins to
    resolve addresses. This
    ; --- is a "crutch" of sorts until the issues with the Win2K3 WINS
    servers can be resolved.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    name resolve order = host wins bcast

    #----------------------------- Name Resolution
    -------------------------------
    # MacroSquish Porthole Internet Name Serving Support Section:
    # Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
    #
    # - WINS Support: Tells the NMBD component of Samba to enable it's WINS
    Server
    #
    # - WINS Server: Tells the NMBD components of Samba to be a WINS Client
    #
    # - WINS Proxy: Tells Samba to answer name resolution queries on
    # behalf of a non WINS capable client, for this to work there must be
    # at least one WINS Server on the network. The default is NO.
    #
    # DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names
    # via DNS nslookups.

    wins support = no
    wins server = 10.2.1.2


    # --------------------------- Printing Options
    -----------------------------
    #
    # Load Printers let you load automatically the list of printers rather
    # than setting them up individually
    #
    # Cups Options let you pass the cups libs custom options, setting it to
    raw
    # for example will let you use drivers on your MacroSquish Porthole
    clients
    #
    # Printcap Name let you specify an alternative printcap file
    #
    # You can choose a non default printing system using the Printing option

    ; load printers = yes
    cups options = raw

    ; printcap name = /etc/printcap
    #obtain list of printers automatically on SystemV
    ; printcap name = lpstat
    ; printing = cups

    # --------------------------- Filesystem Options
    ---------------------------
    #
    # The following options can be uncommented if the filesystem supports
    # Extended Attributes and they are enabled (usually by the mount option
    # user_xattr). Thess options will let the admin store the DOS attributes
    # in an EA and make samba not mess with the permission bits.
    #
    # Note: these options can also be set just per share, setting them in
    global
    # makes them the default for all shares

    ; --- 2007-12-08 due to Unix's heavy use of dotfiles as hidden
    directories, and because it likes to
    ; --- fill up user home directories with these little annoyances, the
    following option was set on
    ; --- to make porthole clients treat the directories and files as
    "hidden". This is NOT on by default. This is
    ; --- also NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    hide dot files = true

    ; --- 2007-12-08 added this line to prevent backslash characters from
    triggering name mangling; without this
    ; --- set to off, names that are "suspect" will be mangled windows-95
    style into DOS 8.3 characters.
    ; --- Mangling is ENABLED by default.
    ; --- This is not a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    mangled names = false

    ; --- 2007-12-08 this option is REQUIRED to fix an issue with delayed
    write errors on MacroSquish Porthole clients.
    ; --- DO NOT REMOVE THIS LINE! YOU HAVE BEEN WARNED!
    ; --- This is not a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    write raw = no

    ; --- 2007-12-18 this option is needed to provide "backwards emulation"
    of Window's case insensitivity.
    ; --- This is not a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    case sensitive = false


    # ----------------------------- Locking Options
    ----------------------------

    ; --- 2007-12-08 all oplocks are disabled for safety; in case we
    selectively activate oplocks for
    ; --- a given share, we will also disable oplocks by file extension, as a
    safety measure. Do not remove
    ; --- the next three lines or the system will suffer slowdowns and other
    issues under heavy load.
    ; --- These are not standard Prominent North American Enterprise Linux
    Vendor GUI options (they don't exist).
    level2 oplocks = false
    oplocks = false
    veto oplock files = /*.mdb/*.MDB/*.ldb/*.LDB/*.dbf/*.DBF/*.cdx/
    *.CDX/*.idx/*.IDX/*.dct/*.DCT/*.dcx/*.DCX/*.fpt/*.FPT/

    ; --- 2007-12-23 enabled kernel oplocks for additional safety, as Linux
    supports these.
    ; --- Note that this is enabled by default anyways and will automatically
    disable if the
    ; --- host OS does not support the feature. We enable it here explicitly.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    kernel oplocks = Yes

    lock spin time = 15


    #============================ Share Definitions
    ==============================

    password server = 10.2.1.1
    realm = PDX.PCFRUIT.COM
    idmap uid = 16777216-33554431
    idmap gid = 16777216-33554431
    ; template shell = /bin/nologin
    ; --- 2007-12-08 This option is enabled to shorten names returned from
    the domain. Typically domain names
    ; --- are returned with their domain attached, ie. PDX\joeuser is the
    account "joeuser" in the "PDX" domain.
    ; --- By enabling this, the domain THAT THE SAMBA SERVICE IS JOINED TO
    will have its domain name omitted from
    ; --- names that are returned from the domain, ie. PDX\joeuser becomes
    just "joeuser" with no PDX attached.
    ; --- DO NOT DISABLE THIS OPTION. DISABLING THIS WILL AFFECT THE USER'S
    HOME SHARES BECAUSE THEY ARE MAPPED
    ; --- USING THE USER'S DOMAIN NAME. This has the effect of changing the
    location that Samba will look for when
    ; --- a user tries to connect to their home share. Note that other
    domains will NOT have their name removed, ie.
    ; --- a user in PCFRUIT will show as PCFRUIT\someotheruser, because it
    only affects the domain name we have joined to.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    winbind use default domain = true

    ; --- 2007-12-08 added to fix backslash naming issue on clients. DO NOT
    REMOVE THIS OPTION.
    ; --- If you have a need to enable this (ie. make it visible) and you
    want to show a backslash, simply
    ; --- comment out the option entirely and Samba will default the
    character to a backslash (\). Do not
    ; --- attempt to assign the backslash manually as it will fail.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    winbind separator = +

    ; encrypt passwords = yes
    ; guest ok = no
    ; guest account = nobody
    ; encrypt passwords = yes
    ; guest ok = no
    ; guest account = nobody


    ; --- 2007-12-08 added to force all shares visible by default. This is a
    deviation from
    ; --- the Prominent North American Enterprise Linux Vendor GUI tool as
    ; --- it attempt to set every share it creates individually. By setting
    the value here in the global section,
    ; --- we can ensure that all shares inherit this setting by default.
    Please do not change it; if you do need to change it
    ; --- you will need to go to each share definition and define it there,
    otherwise your shares will not be visible in
    ; --- the MacroSquish Porthole Exploder window!

    ; --- This is not available on a global basis. The Prominent North
    American Enterprise Linux Vendor GUI
    ; --- does provide for it on a share-by-share basis.
    browseable = yes

    [homes]
    comment = Home Directories
    path = /home/%S
    ; --- 2007-12-08 must be set to "no" for this section, otherwise a ghost
    share will appear
    browseable = no
    writeable = yes
    ; --- 2007-12-08 activated stock permission setting by uncommenting
    valid users = %S
    ; valid users = MYDOMAIN\%S
    ; --- 2007-12-08 added file creation mask to force correct permissions on
    initial file creates
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    create mask = 0660
    ; --- 2007-12-08 added directory creation mask to force correct
    permissions on initial directory creates
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    directory mask = 0770
    ; --- 2007-12-08 added well-known/documented option to force account to
    user's account upon access. It is
    ; --- suggested that you keep this to prevent file ownership issues when
    looking at user home directories from
    ; --- an administrative level.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    force user = %S

    [printers]
    comment = All Printers
    path = /var/spool/samba
    browseable = no
    ; guest ok = no
    ; writeable = no
    printable = yes

    [home]
    path = /home
    writeable = yes
    browseable = no
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support,
    ; --- added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes

    [depts]
    path = /depts
    writeable = yes
    browseable = no
    guest ok = yes
    admin users = admin2, admin1, admin3, admin4
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support,
    ; --- added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes

    [share]
    path = /share
    writeable = yes
    browseable = no
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support,
    ; --- added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes

    [accounting]
    path = /depts/acct
    writeable = yes
    ; browseable = yes
    guest ok = yes
    comment = Department Share - Accounting
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [buyers]
    comment = Department Share - Buyers
    path = /depts/buyers
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [hr]
    comment = Department Share - HR
    path = /depts/hr
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [is]
    comment = Department Share - Information Services
    path = /depts/is
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [management]
    path = /depts/mgmt
    writeable = yes
    ; browseable = yes
    guest ok = yes
    comment = Department Share - Management
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [operations]
    comment = Department Share - Operations
    path = /depts/ops
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [sales]
    comment = Department Share - Sales
    path = /depts/sales
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [archive]
    comment = Shared Applications
    path = /share/archive
    writeable = yes
    browseable = no
    guest ok = no
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    oplocks = true
    level2 oplocks = true

    [dev]
    comment = Development
    path = /share/dev
    writeable = yes
    browseable = no
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support,
    ; --- added this option to allow for permissions to be set
    ; --- based on the accounting having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770

    [pcf_public]
    comment = Public Non-Sensitive Files
    path = /share/public
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to
    ; --- allow for permissions to be set based on the accounting having
    write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    ; --- NEITHER of these are standard Prominent North American Enterprise
    Linux Vendor GUI options (they don't exist in the GUI).
    force create mode = 0666
    force directory mode =0777

    [test]
    comment = Testing Area - Not For General Use
    path = /share/test
    writeable = yes
    ; browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    ; --- 2007-12-18 this is strictly a test environment. Admin
    functionality has been disabled
    ; --- to facilitate permissions testing.
    ; admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to
    ; --- allow for permissions to be set based on the user having write
    ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770
    ; --- 2007-12-18 oplock functionality can be tested on this share
    selectively.
    level2 oplocks = true
    oplocks = true
    ; veto oplock files =
    ; --- 2007-12-18 force a flush of all buffers to disk once a client sends
    their buffers over
    ; --- to the service. This is NOT a standard Prominent North American
    Enterprise Linux Vendor GUI option (it doesn't exist).
    ; sync always = yes

    [vp]
    comment = Visual Package for ERP/accounting based on Very Frumpy
    Programming language
    path = /share/vp
    writeable = yes
    read only = no
    ; browseable = yes
    ; --- 2007-12-08 added to force admin access based on account
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option
    ; --- to allow for permissions to be set based on the accounting having
    write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770
    ; --- 2007-12-13 as this is a critical share, this function has been
    disabled to prevent potential conflict.
    ; dos filemode = yes
    ; --- 2007-12-18 oplock functionality can be tested on this share
    selectively.
    level2 oplocks = true
    oplocks = true
    veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/*.fpt/*.FPT/*.cdx/
    *.CDX/*.idx/*.IDX/*.ndx/*.NDX/*.dct/*.DCT/*.dcx/*.DCX/*.dbc/*.DBC/*.dll/
    *.DLL/
    ; --- 2007-12-23 added these parameters as part of Very Old Accounting
    Packager's recommendations
    create mask = 0660
    directory mask = 0770
    guest ok = yes

    [apps]
    comment = Testing Area - Not For General Use
    path = /share/apps
    writeable = yes
    browseable = yes
    guest ok = yes
    ; --- 2007-12-08 added to force admin access based on account
    ; --- 2007-12-18 this is strictly a test environment. Admin
    functionality has been disabled
    ; --- to facilitate permissions testing.
    ; admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    ; --- 2007-12-12 per Prominent North American Enterprise Linux Vendor
    Global Support, added this option to allow for permissions to be set
    ; --- based on the user having write ability to the object.
    ; --- This is NOT a standard Prominent North American Enterprise Linux
    Vendor GUI option (it doesn't exist).
    dos filemode = yes
    ; --- 2007-12-13 this next setting is part of a two-part fix that
    addresses issues with MacroSquish Obfuscator documents
    ; --- being saved, only to be later re-openned as "read only". The issue
    is in MacroSquish Obfuscator, not in Samba, and
    ; --- typically affects MacroSquish Weird documents (it creates a temp
    document, you save it, it deletes the old doc
    ; --- and renames the temp). The other half of the fix requires that the
    sticky bit be set for the group "chmod g+s "
    force create mode = 0660
    force directory mode =0770
    ; --- 2007-12-18 oplock functionality can be tested on this share
    selectively.
    level2 oplocks = true
    oplocks = true
    ; veto oplock files =
    ; --- 2007-12-18 force a flush of all buffers to disk once a client sends
    their buffers over
    ; --- to the service. This is NOT a standard Prominent North American
    Enterprise Linux Vendor GUI option (it doesn't exist).
    ; sync always = yes

    [vmware]
    ; --
    ; -- This share hosts VMWare Images.
    ; --

    path = /share/vmware
    comment = VMWare Virual Machine Images
    browseable = Yes
    read only = No
    writeable = Yes
    guest ok = No
    dos filemode = yes
    level2 oplocks = true
    oplocks = true
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    force create mode = 0660
    force directory mode = 0770
    veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/*.fpt/*.FPT/*.cdx/
    *.CDX/*.idx/*.IDX/*.ndx/*.NDX/*.dct/*.DCT/*.dcx/*.DCX/*.dbc/*.DBC/*.dll/
    *.DLL/

    [stub]
    ; --
    ; -- Default Share Template
    ; --

    ; -- Copy this share template ONLY. Do not copy any other share for a
    template as you
    ; -- may accidentally damage or loose it.
    path = /share
    comment = Stub Template (for internal use only)
    browseable = Yes
    read only = No
    writeable = Yes
    guest ok = No
    dos filemode = yes
    level2 oplocks = true
    oplocks = true
    admin users = PDX+admin1 PDX+admin3 PDX+admin4 PDX+admin2
    force create mode = 0660
    force directory mode = 0770
    veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/*.fpt/*.FPT/*.cdx/
    *.CDX/*.idx/*.IDX/*.ndx/*.NDX/*.dct/*.DCT/*.dcx/*.DCX/*.dbc/*.DBC/*.dll/
    *.DLL/



    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  15. Re: [Samba] Airing Dirty Laundry

    On Tuesday 27 May 2008 04:46:45 pm Avery Payne wrote:
    >>...

    >
    > Yes, it's a mess, yes it needs some work - but that's why I'm posting it
    > here, eh?


    Instead of posting an unreadable smb.conf file, please be kind to the people
    who want to help you. You could send the output of: testparm -s

    Testparm will output only those parameters that are set at non-default value
    and presents it in a much more readable format. Try it, you will seee what we
    mean.

    - John T.
    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

  16. [Samba] Re: Airing Dirty Laundry

    On Tue, 27 May 2008 17:40:41 -0500, John H Terpstra wrote:

    > Instead of posting an unreadable smb.conf file, please be kind to the
    > people who want to help you. You could send the output of: testparm -s
    >
    > Testparm will output only those parameters that are set at non-default
    > value and presents it in a much more readable format. Try it, you will
    > see what we mean.


    Was going to do that originally (sigh). I'll have to tend to it
    tomorrow. It takes time to "sanitize" the output.

    --
    To unsubscribe from this list go to the following URL and read the
    instructions: https://lists.samba.org/mailman/listinfo/samba

+ Reply to Thread