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.
@KBOYLE: DSfW *is* /includes Samba. That page you're citing simply tell you not to install novell-samba again.
@Prindl: 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.
Micro Focus Knowledge Partner
No emails please!
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.
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)
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.
sorry for the late reply. Perhaps you have solved this already. If I remember correctly I set the client max protocol = NT1 in smb.conf global section.
I also received a update from Novell support