We're trying to migrate RHEL3 and CentOS4 based samba servers over to CentOS5, but it's a bleeding disaster. We cannot get it to work reliably with any version of CentOS5, i386 or x86_64, the included 3.0.x version of samba or 3.4.x/3.5.x compiled from source.
The symptoms are: read access is extremely slow, write access seems to work in principle (e.g. creating a zeros-sized file on a share), but writing even small files (100k) to the share eventually times out with "out of memory or disk space" errors. These shares are home directories NFS-mounted on the samba server. Shares of local disks work fine as expected.
We have played with oplock settings and got some improvements, but not reliably, and this seems to effect XP and Seven clients differently.
Surely we are not the first to run into this sort of issue? Given the range of tested software, the problem appears to be specific to CentOS5.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
Am Freitag, den 16.04.2010, 15:00 +0200 schrieb lhecking@users.sourceforge.net:
We're trying to migrate RHEL3 and CentOS4 based samba servers over to CentOS5, but it's a bleeding disaster. We cannot get it to work reliably with any version of CentOS5, i386 or x86_64, the included 3.0.x version of samba or 3.4.x/3.5.x compiled from source.
The symptoms are: read access is extremely slow, write access seems to work in principle (e.g. creating a zeros-sized file on a share), but writing even small files (100k) to the share eventually times out with "out of memory or disk space" errors. These shares are home directories NFS-mounted on the samba server. Shares of local disks work fine as expected.
We have played with oplock settings and got some improvements, but not reliably, and this seems to effect XP and Seven clients differently.
Surely we are not the first to run into this sort of issue? Given the range of tested software, the problem appears to be specific to CentOS5.
If this was a general CentOS problem you would propably find tons of information on bugs.centos.org and bugzilla.redhat.com. I bon't use samba on CentOS 5 myself but it's really hard to believe that it is a CentOS related problem. I rather think it is some trivial common problem like network issues (duplex/speed missmatch) or some problem with the storage.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Christoph Maser a écrit :
We're trying to migrate RHEL3 and CentOS4 based samba servers over to CentOS5, but it's a bleeding disaster. We cannot get it to work reliably with any version of CentOS5, i386 or x86_64, the included 3.0.x version of samba or 3.4.x/3.5.x compiled from source.
The symptoms are: read access is extremely slow, write access seems to work in principle (e.g. creating a zeros-sized file on a share), but writing even small files (100k) to the share eventually times out with "out of memory or disk space" errors. These shares are home directories NFS-mounted on the samba server. Shares of local disks work fine as expected.
We have played with oplock settings and got some improvements, but not reliably, and this seems to effect XP and Seven clients differently.
We're running a CentOS 5 Samba server in our local town hall, mostly Linux clients, but also the odd XP machine, with a simple configuration: one open public share, then a series of protected shares.
http://www.microlinux.fr/doc_en_stock/samba.html
Until now, folks seem to appreciate the setup as "vachement rapide" (something like : furiously fast).
I have to add that standard servers like Samba, Apache, MySQL, NFS, ... never (ever) gave me headaches with CentOS. That's why I'm using this fine distro.
</propaganda>
Cheers from the sunny South of France.
Niki
Someone wrote:
We're trying to migrate RHEL3 and CentOS4 based samba servers over to CentOS5, but it's a bleeding disaster. We cannot get it to work reliably with any version of CentOS5, i386 or x86_64, the included 3.0.x version of samba or 3.4.x/3.5.x compiled from source.
<snip> Here's a question: are you using your old configuration files? You might want to compare the default from the install with the old ones - there may be deprecated or defunct or invalid options.
mark
Here's a question: are you using your old configuration files? You might want to compare the default from the install with the old ones - there may be deprecated or defunct or invalid options.
Have used the same smb.conf for years on RHEL3 while moving from 3.0.x to 3.[2-4].x.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
On Fri, 2010-04-16 at 14:29 +0100, lhecking@users.sourceforge.net wrote:
Here's a question: are you using your old configuration files? You might want to compare the default from the install with the old ones - there may be deprecated or defunct or invalid options.
Have used the same smb.conf for years on RHEL3 while moving from 3.0.x to 3.[2-4].x.
does testparm reveal any issues with the config?
Brian Sr wrote:
On Fri, 2010-04-16 at 14:29 +0100, lhecking@users.sourceforge.net wrote:
Here's a question: are you using your old configuration files? You might want to compare the default from the install with the old ones - there may be deprecated or defunct or invalid options.
Have used the same smb.conf for years on RHEL3 while moving from 3.0.x to 3.[2-4].x.
does testparm reveal any issues with the config?
He said shares on local filesystems were fine but shares on NFS were borked.
From: "lhecking@users.sourceforge.net" lhecking@users.sourceforge.net
The symptoms are: read access is extremely slow, write access seems to work in principle (e.g. creating a zeros-sized file on a share), but writing even small files (100k) to the share eventually times out with "out of memory or disk space" errors. These shares are home directories NFS-mounted on the samba s erver. Shares of local disks work fine as expected.
Just in case, what's your nic MTU...? Maybe read http://serverfault.com/questions/68330/samba-sharing-an-nfs-mount-point
JD
On 16/04/2010 14:00, lhecking@users.sourceforge.net wrote:
We're trying to migrate RHEL3 and CentOS4 based samba servers over to CentOS5, but it's a bleeding disaster. We cannot get it to work reliably with any version of CentOS5, i386 or x86_64, the included 3.0.x version of samba or 3.4.x/3.5.x compiled from source.
The symptoms are: read access is extremely slow, write access seems to work in principle (e.g. creating a zeros-sized file on a share), but writing even small files (100k) to the share eventually times out with "out of memory or disk space" errors. These shares are home directories NFS-mounted on the samba server. Shares of local disks work fine as expected.
We had a similar after issues migrating from a Solaris 8 2.x Samba install to CentOS 5 . We had all sorts of timeouts, and weird slowness and random "read only" messages.
Setting
locking = No
in the globals of smb.conf fixed it.
In our case we suspect it has something to do with locking differences over NFS between Solaris and CentOS clients accessing a CentOS NFS server but didn't have time to fully investigate (we were just glad it got fixed!). If this works for you then maybe there's something more to investigate...
Dan
We have played with oplock settings and got some improvements, but not reliably, and this seems to effect XP and Seven clients differently.
Surely we are not the first to run into this sort of issue? Given the range of tested software, the problem appears to be specific to CentOS5.
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
From: Daniel Bird dbird@sgul.ac.uk
Setting locking = No in the globals of smb.conf fixed it.
Keep in mind that: "Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter."
JD
On 04/16/2010 04:23 PM, John Doe wrote:
From: Daniel Birddbird@sgul.ac.uk
Setting locking = No in the globals of smb.conf fixed it.
Keep in mind that: "Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter."
Indeed, however smb locking still properly reports "this file is in use by...." etc. on the smb side. If fact it seems to have had little effect except for now properly reporting who is using the file instead of always reporting the file is in use and locked by the owner.
Like I said, we still need to investigate more fully however the we see the issue on all NFS file systems when using the rpms from both the 3.0.33 CentOS and samba-3x series from RedHat 5.5. Like the OP, local file systems do not exhibit this issue.
D
JD
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Daniel Bird wrote:
On 04/16/2010 04:23 PM, John Doe wrote:
From: Daniel Birddbird@sgul.ac.uk
Setting locking = No in the globals of smb.conf fixed it.
Keep in mind that: "Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter."
Indeed, however smb locking still properly reports "this file is in use by...." etc. on the smb side. If fact it seems to have had little effect except for now properly reporting who is using the file instead of always reporting the file is in use and locked by the owner.
Like I said, we still need to investigate more fully however the we see the issue on all NFS file systems when using the rpms from both the 3.0.33 CentOS and samba-3x series from RedHat 5.5. Like the OP, local file systems do not exhibit this issue.
Can't you samba-export at the source instead of the nfs mount? Even if it works it seems like an inefficient way to do things.
Can't you samba-export at the source instead of the nfs mount? Even if it works it seems like an inefficient way to do things.
Yes, that makes perfect sense and thats the second stage of our migration from the old E450 Solaris 8 box (which hosted everything via a single samba instance, with NFS mounts from other storage that didn't support running samba) . We ARE moving to direct samba mappings via the netlogon scripts to the servers hosting the file systems, but we have over 1200 smb shares across 40 or so 1Tb+ file systems and that all takes time and testing... :-)
However, at the risk of being a pedant, that doesn't give us a explanation as to why the same setup on CentOS & RHEL resulted in the behavior we experienced. NFS mounts are surely not that uncommon on samba servers and one would expect the locking mechanisms to cope with that scenario. It surely does on our old Solaris box. We will be investiaging this further since our migration is going to take a couple of months and like JD pointed out in a previous post the no locking option shouldn't be needed.
D
Daniel Bird writes: [...]
However, at the risk of being a pedant, that doesn't give us a explanation as to why the same setup on CentOS & RHEL resulted in the behavior we experienced. NFS mounts are surely not that uncommon on samba servers and one would expect the locking mechanisms to cope with that scenario. It surely does on our old Solaris box. We will be investiaging this further since our migration is going to take a couple of months and like JD pointed out in a previous post the no locking option shouldn't be needed.
I found these http://kbase.redhat.com/faq/docs/DOC-1984 http://lists.samba.org/archive/samba/2009-May/148403.html and we're in the situation described (NetApp filer with no CIFS license).
Investigating one of our sites with a working CentOS5 samba server shows that they indeed have "posix locking = no" in smb.conf.
The bit that is still unclear to me, however, is that RH apply this to all of RHEL3,4,5, whereas we don't see this problem under RHEL3.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
lhecking@users.sourceforge.net wrote:
Daniel Bird writes: [...]
However, at the risk of being a pedant, that doesn't give us a explanation as to why the same setup on CentOS & RHEL resulted in the behavior we experienced. NFS mounts are surely not that uncommon on samba servers and one would expect the locking mechanisms to cope with that scenario. It surely does on our old Solaris box. We will be investiaging this further since our migration is going to take a couple of months and like JD pointed out in a previous post the no locking option shouldn't be needed.
I found these http://kbase.redhat.com/faq/docs/DOC-1984 http://lists.samba.org/archive/samba/2009-May/148403.html and we're in the situation described (NetApp filer with no CIFS license).
Investigating one of our sites with a working CentOS5 samba server shows that they indeed have "posix locking = no" in smb.conf.
The bit that is still unclear to me, however, is that RH apply this to all of RHEL3,4,5, whereas we don't see this problem under RHEL3.
What about the default options that have changed? Have you tried setting them back to what worked with RHEL3? Be sure you are running nfsv3, udp, etc.
From: Daniel Bird dbird@sgul.ac.uk
Setting locking = No in the globals of smb.conf fixed it.
Keep in mind that: "Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter."
Trying again since it didn't seem to make it last time:
Well, re-exporting NFS imports via Samba is not really a supported way to do things either, exactly due to the problems the OP is encountering. So, if you are going to live on the edge, you may have to get closer to it to get things to work.
This is usually an NFS issue, not a Samba one. Try setting "posix locking = no" in smb.conf.
Ian
On 04/16/10 15:00, lhecking@users.sourceforge.net wrote:
We're trying to migrate RHEL3 and CentOS4 based samba servers over to CentOS5, but it's a bleeding disaster. We cannot get it to work reliably with any version of CentOS5, i386 or x86_64, the included 3.0.x version of samba or 3.4.x/3.5.x compiled from source.
The symptoms are: read access is extremely slow, write access seems to work in principle (e.g. creating a zeros-sized file on a share), but writing even small files (100k) to the share eventually times out with "out of memory or disk space" errors. These shares are home directories NFS-mounted on the samba server. Shares of local disks work fine as expected.
We have played with oplock settings and got some improvements, but not reliably, and this seems to effect XP and Seven clients differently.
Surely we are not the first to run into this sort of issue? Given the range of tested software, the problem appears to be specific to CentOS5.
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Try mounting your NFS volumes with:
rsize=32768,wsize=32768
Are the NFS servers on the same network speed as the samba servers?
Glenn