[Samba] Re: dabase file and oplocks
Luca Ferrari wrote: > On Wednesday 24 September 2008 Luca Ferrari's cat, walking on the keyboard, > wrote: >> I've tried to use the options sync always and strict sync, but nothing >> changed. I compiled the 3.2.4 on the linux client machine and mounted the >> exported file system using cifs, but nothing changed. Still the data on the >> server is corrupted, as the program cannot get the lock on the files. >> I've also tried to swtich on and off the oplocks, without any difference. >> In the previous versions of samba (3.0.2) it worked, so I don't understand >> what could be the different configuration. Anyone has an idea? Place the following in the global section: kernel oplocks = Yes You shouldn't need it, but it wouldn't hurt. It's only supported on *BSD and Linux. Place the following in your share section: oplocks = false level2 oplocks = false veto oplock files = /*.dat/*.DAT/ That above line will prevent oplocks from touching files that match the pattern. In your case, no oplocks will be granted on *.dat files. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Re: Samba with 2 NICs
Scott Lovenberg wrote: > Avery Payne wrote: >> hamacker wrote: [snip] >>> I can't understand why WinXP can logon and win95/98 is not, if enable >>> 2 NICs on my system. >> The TCP/IP stack in Win95/98 was not exactly, um, "state of the art" >> (ping of doom anyone?). It could be something as simple as the Win95/98 >> stack doesn't support multihomed hosts properly. [snip] > Another thought; are you using a managed switch? A simple layer 2 > switch will get very confused if it sees the same MAC address twice on > different ports, and will usually start multicasting over every switch > port. [snip] Easy way to test it - use a hub and see if the problem goes away. :) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Re: smbstatus - switched off computers are sometimes showed
Vlastimil Šetka wrote: > > Sometimes (cca twice a day) smbstatus return error output like this: > tdb(/var/run/samba/sessionid.tdb): rec_read bad magic 0xd9fee666 at > offset=116988 It looks like you have an issue with a record. Stop your service for a moment, go in and cp your files in /var/run/samba to a new directory, say to /var/run/samba.backup, then go into /var/run/samba and do this: tdbbackup -sbak *.tdb tdbbackup -v -sbak ...then start Samba. The first makes a backup of your tdb tables; the second verifies (and restores if needed) your tdb records. This is safe, but if there was any issue, you can always restore your files from the copy in /var/run/samba.backup that you made. > It's a bug or a feature and smbstatus is only informative? It's solved > in some newer version? Can you tell me about better source for connected > user status? On RHEL52 here and just moved up to 3.0.28 as part of an update from stock RHEL50. Significant difference in stability and behavior from the stock 3.0.25b. Twice-a-week locking issues have just "disappeared" and using the Computer Management tool attached to the Samba server shows actual files open instead of "ghost files". Does "apt-get update && apt-get upgrade" show any entries for Samba? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Re: Samba with 2 NICs
hamacker wrote: > I did that. > I test, and everything is OK. > It's not misconfiguration. > > When 2 NICs bonded (or 2 NICs only enabled), WinXP can logon into > domain and win95/98 can not. If I disable one NIC then any OS can > logon into domain. > > I can't understand why WinXP can logon and win95/98 is not, if enable > 2 NICs on my system. The TCP/IP stack in Win95/98 was not exactly, um, "state of the art" (ping of doom anyone?). It could be something as simple as the Win95/98 stack doesn't support multihomed hosts properly. Try the following: * Make Win95/98 point to just ONE address only; use an LMHOSTS file with just ONE IP entry specified for the Samba server. * Make your Samba install a WINS server, and point the Win95/98 boxes at it. This isn't supposed to matter, but then again, I've seen modern Win2k3 networks running WINS to help things along... -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Looking for Information on Commercial Deployments
Hi folks! I'm looking for someone who has placed a commercial deployment of Samba into production in or around the Portland, OR area. If you are on the US west coast, or can call me during work hours in the Pacific time zone, I would even be happy to contact you by phone. My department at work has a few questions, such as: - Size of the deployment (in servers and users) - How critical is the deployment to your business (incidental, department, critical, etc.) - What trade-offs have you seen when compared to using a "traditional" Windows server deployment? (Compatibility, service management, etc.) - What benefits have you gained vs. a "traditional" Windows server deployment? (bonus features or services) - What kind of model did you adopt for your filesystem and share level security? Specifically, what scheme did you adopt for file ownership/ group on the filesystem? Have you had issues with needing to "fix" file permissions? If you use ACLs, are you using a POSIX-based ACL system (which limits emulation of Windows file permissions), or have you found a better way to provide a finer-grained control? Do you use Windows administation tools to set file permissions at all, and if so, how has that worked for you? This is a question we're very curious about. - What is your choice of back-end for Samba to store its data in? tdb? ldap? something else? All of these questions will help us assess our current deployment, while gaining insight into improvements that we may be able to make. Any information you have would be greatly appreciated! Feel free to email me directly at [EMAIL PROTECTED] Thanks in advance! -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Looking for Information on Commercial Deployments
Hi folks! I'm looking for someone who has placed a commercial deployment of Samba into production in or around the Portland, OR area. If you are on the US west coast, or can call me during work hours in the Pacific time zone, I would even be happy to contact you by phone. My department at work has a few questions, such as: - Size of the deployment (in servers and users) - How critical is the deployment to your business (incidental, department, critical, etc.) - What trade-offs have you seen when compared to using a "traditional" Windows server deployment? (Compatibility, service management, etc.) - What benefits have you gained vs. a "traditional" Windows server deployment? (bonus features or services) - What kind of model did you adopt for your filesystem and share level security? Specifically, what scheme did you adopt for file ownership/ group on the filesystem? Have you had issues with needing to "fix" file permissions? If you use ACLs, are you using a POSIX-based ACL system (which limits emulation of Windows file permissions), or have you found a better way to provide a finer-grained control? Do you use Windows administation tools to set file permissions at all, and if so, how has that worked for you? This is a question we're very curious about. - What is your choice of back-end for Samba to store its data in? tdb? ldap? something else? All of these questions will help us assess our current deployment, while gaining insight into improvements that we may be able to make. Any information you have would be greatly appreciated! Feel free to email me directly at [EMAIL PROTECTED] Thanks in advance! -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Looking for Information on Commercial Deployments
Hi folks! I'm looking for someone who has placed a commercial deployment of Samba into production in or around the Portland, OR area. If you are on the US west coast, or can call me during work hours in the Pacific time zone, I would even be happy to contact you by phone. My department at work has a few questions, such as: - Size of the deployment (in servers and users) - How critical is the deployment to your business (incidental, department, critical, etc.) - What trade-offs have you seen when compared to using a "traditional" Windows server deployment? (Compatibility, service management, etc.) - What benefits have you gained vs. a "traditional" Windows server deployment? (bonus features or services) - What kind of model did you adopt for your filesystem and share level security? Specifically, what scheme did you adopt for file ownership/ group on the filesystem? Have you had issues with needing to "fix" file permissions? If you use ACLs, are you using a POSIX-based ACL system (which limits emulation of Windows file permissions), or have you found a better way to provide a finer-grained control? Do you use Windows administation tools to set file permissions at all, and if so, how has that worked for you? This is a question we're very curious about. - What is your choice of back-end for Samba to store its data in? tdb? ldap? something else? All of these questions will help us assess our current deployment, while gaining insight into improvements that we may be able to make. Any information you have would be greatly appreciated! Feel free to email me directly at [EMAIL PROTECTED] Thanks in advance! -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[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
[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. :D 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 sp
[Samba] Re: Samba 3.0.25b on centos 5.1 a lot of signal 11 very unstable!!!
On Tue, 26 Feb 2008 22:12:53 -0800, Alberto Moreno wrote: > > The only problem is this new server, i read about some changes > with samba 3.0.25b and oldest version, since we add this server to the > domain we had been having problems, we enable the roaming profile to our > windows clients, but some times the server doesn't update the user > profile, on other situations we lost the profile, example firefox > settings, or if the user update some excel file next day appear with no > changes. Roaming profiles are just problematic, even on native Windows servers. I have seen several roaming profiles implode on WinXP client boxes. I've also seen bad behavior with Win2k client/server setups as well. Symptoms include the client creating new profiles, ignoring existing profiles, or dialogs indicating profile corruption. > >We have almost 3GB of core dumps since we setup samba inside > winbind folder, look this is my smb.conf file: [ lots of stuff snipped out ] > > lib/fault.c:dump_core(181) dumping core in /var/log/samba/cores/ winbindd [ even more stuff snipped out] > [0x645c97] #19 winbindd [0x6443f2] #20 winbindd [0x615368] #21 > winbindd(main+0x94d) [0x615dbd] #22 /lib/libc.so.6(__ > libc_start_main+0xdc) [0x21fdec] #23 winbindd [0x614061] : 13 Time(s) > -- > > Hope this info give some point to start debugging this problem, does > someone see what is causing the problem? Thanks all for your time, if u > need more info please let me know, thanks!!! I'm no Samba or programming expert, but that last line looks like a libc segfault. Sig 11 errors a long time ago used to implicate RAM issues, usually due to bad contacts or faulty RAM chips.This may sound silly but try powering down the machine, unseating and reseating all of your RAM. If it continues, try reducing the RAM and see if the issue goes away (due to a bad RAM stick). Just my .02 cents. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[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 + (UTC) Avery Payne > <[EMAIL PROTECTED]> wrote: > >> Question: >> >> We recently moved to a Samba-based file server, which holds mission- >> critical data on it (.dbf files used by our Accounting software, etc.) >> The goal was to create a file server that had excellent performance >> while providing Volume Management, but we felt that something like >> Veritas was overkill for our needs. >> >> Design Goals: >> - Redundant Hardware >> - Manual Failover (this was an acceptable solution) > [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
[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
[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 Com
[Samba] Looking for a set of definitive answers (long)
Question: We recently moved to a Samba-based file server, which holds mission- critical data on it (.dbf files used by our Accounting software, etc.) The goal was to create a file server that had excellent performance while providing Volume Management, but we felt that something like Veritas was overkill for our needs. Design Goals: - Redundant Hardware - Manual Failover (this was an acceptable solution) - Very large storage capacity (minimum 1 Terabyte) - Better than 100Mbyte/sec throughput - Volume Management, Journaled Filesystem - Drop-In Replacement for aging Win2k file server - Use existing admin tools to avoid retraining The proposed solution was a Samba file server running on a pair of redundant servers, with one connected to an eSATA raid box, with LVM and Ext3 providing volume management and journaling. Our transition was a bit rough, but in the end it has been very stable and fast. We have been really pleased with the performance of the hardware/software combo, seeing sustained throughput of about 250Mbyte/sec with peaks as high as 300Mbyte/sec. But along the way, we encountered some oddities, and I have some remaining questions. First, the oddities (long-time Samba devs and admins, take this with a grain of salt, when I say oddity I mean it from the perspective of an experienced Windows administrator): - File permissions do not behave as expected (from the viewpoint of other staff working with the server). The *nix permission bits cause a user, group, and "Everyone" entry to become permanent and persistent. There was some initial grousing over this fact as our long-time Windows admin scratched his head over why he couldn't remove these entries as he saw fit. After explaining that there would always be three settings no matter what, that they could never be deleted, and that they represented actual filesystem-level bits that wouldn't go away, it was accepted. I didn't notice if this was in the docs or not, but I certainly didn't find it. It also meant enabling ACLs on all of the filesystems and doing some creative thinking with the permissions. The closest I could do was to map all files as owner root, group set to Domain Admins, and Everyone set to disallowed; members of the IT staff would be mapped with the "admin users" parameter; from there, any additional permissions would be mapped via ACLs. We've found that this method has the closest behavior to a "real" Windows server and has satisfied everyone. - Permissions don't propigate through the filesystem. On a Real Windows Box(tm) you would be able to set permissions at the parent level of a directory and have them show up for each child object. Because the filesystem semantics are not the same in *nix-land, you need to go into the directly and manually propigate the permissions, or if you're stuck trying to administer permissions through a windows session (like the other IT staffers in my department), using the Advanced setting to force-reset all permissions on all child objects. This has also caused a bit of grousing as we have several nested directories with a heiarchy of permissions; getting one parent directory wrong means rebuilding permissions for several child directories as well. I have never been able to get a satisfactory answer as to how to resolve this issue, other than the process I described above (which I had to resolve for myself without documentation). - To oplock or not to oplock: that is the question The documentation is not entirely clear about when you should and shouldn't use oplocks on shared files. It would have been much simplier (IMHO) to simply say "use your best judgement, BUT if you are using shared data files like Access or Excel or DBF's, you will want to disable them or you'll have problems!". Yes those words show up on newsgroups, but it should also show up in the documentation clearly. - Office file locking workaround(s) were not immediately obvious Buried in the nice (but large) Official Samba Reference and HOWTO is a fix for sharing Word and Excel files through Samba, which involves using the sticky bit for group permissions. While the fix was adequate and works well, it should have been I think a little more prominently displayed in the documentation. - What? You want me to unlock that file? We have had recurring instances where a workstation on the network has seized a DBF file and held onto it, not allowing any other workstation or server to perform writes to the file. This locking issue shows up in random intervals and always requires that we have the person quit the program we are using and log back in. It is not an application issue that we can determine - the rest of the system continues to funciton, it just prevents one of our servers (or anyone else) from locking the file. - Speaking of which - just WHO does have that file lock? For some reason, using the computer management tool in a windows workstation sh
