OES2018 SP1DSfW Samba problems

There is a real problem with Samba performance in OES2018 SP1. Unfortunately the DSfW Server only supports Samba as SMB file server product.

Till OES2018 without SP1 one could use Samba to access NSS Volumes on the DSfW server to distribute settings, which one did not want to place on the SYSVOL as there is no real user rights differentiation possible.

Now you can do this as well, but suffer a network throughput of less than 1 kbyte/s. (If you access the same files through Novell client you get an adequate throughput.) So it is useless to put any NSS Volume on a DSfW server.



    I have very little DSfW experience but I have an upcoming deployment so I'm just delving into things. 

    According to the OES 2018 SP1: Domain Services for Windows Administration Guide, SAMBA is one of the Unsupported Service Combinations.

    If you believe you have a supported configuration, I would open a Service Request and have tech support look at it.

  • : DSfW *is* /includes Samba. That page you're citing simply tell you not to install novell-samba again.

    : I know, this doesn't help a lot, but yes, Samba performance sucks, but not as much as you describe it, there must be a more fundamental issue here. I'd start with a Lan Trace.


    DSfW Includes a special version of Samba. I don't know if there are any performance differences in the DSfW version and you can't install the SLES or Novell version to see if it makes a difference. That's why I suggested an SR.

  • Over the weekend I have moved the NSS volume from this server to a Windows server, changed all references to the new location and assigned the correct acls to the NTFS filesystem - so no use of Samba filesharing any more except the sysvol.

    I have not digged deeper into the issue, but it had something to do with concurrent file access - if a single user accessed just one file performance was poor but bearable - but if one or more users accesssed several files concurrently it got unusable.

  • Hi,

    I have the same or similar issue with OES2018SP1. Very slow performance with SMB, more or less no performance at all.

    ncp (filr) and scp works fine, write to the server with smb works fine too.

    But downloading files is horrible, stops and timeout after 50 KB and times out.

    I can do a lan trace but have no customer with dsfw oes1015 or 2018 without SP to compare too.

    Have a SR related to t his (101246679281)


  • At the moment I have no old DSfW server left. But I know, that it was working in OES 2015 and OES 2018. Since I moved the volume to NTFS on Windows the performance is awesome - even compared to the OES 2015 and OES 2018 Samba performance - despite the fact that the underlying hardware is absolutely the same, because they run on the same ESXi host.
  • My customer had no performance issue on DSFW/OES2015 and that was on lower grade hardware then now and a XEN platform. I dont want to move the storage to windows/ntfs if I can avoid that since I think it something that is fixable.

    So I'm waiting to see if they can help fix the problem, will get back if I got a working solution


  • I had to dig further into the Samba problem with DSfW and OES2018 SP1. I found out, that the implementation of the SMB 2 and the SMB 3 is totally dysfunctional.

    On the sysvol you get severe problems, if you try to copy files of over 100 KB from a Windows 7 or Windows 10 PC. I then tested this on an old WinXP VM (where you cannot logon as domain user since OES2018 SP1, but can access all domain shares) and found a quite normal behaviour.

    This led me to the suspicion, that SMB 2 and SMB 3 on the Samba server side is the culprit.

    I set "server max protocol = NT1" in the smb.conf and voila sysvol fileacces is back to normal.

    But it would be nice, if we get a samba version, with a functional SMB2 and SMB3 server.

  • I can only confirm this, disable smb2 and 3 is a work around that makes the files accessable


  • How do you enable/force SMB 1 only? I also have file transfer issues on Windows 10 version 1909. Windows 7 works fine though.