Topic: Sage Line 50 Samba Issue

[d6hq]

Just moved a production server to new hardware using Affa which of course requires tha both boxes are at the same os level so we yummed both before doing the move to 7.5.1. Everything has worked correctly except that Samba and Sage Line 50 or Sage Accounts 2010 to give it its proper name won't now play nicely.

On the old hardware Sage performed correctly but on the new box we get problems opening the data files and what appear to be network timeouts but aren't. We have temporarily moved the data store to a NAS as a workaround but really need a long term solution.

Has anybody got a working smb.conf for a Sage shared data drive under 7.5.1 ? It would appear our highly tuned version from the old install needs a complete revision.  Change in the oplocks directives ?

[byte]

On the old hardware Sage performed correctly but on the new box we get problems opening the data files and what appear to be network timeouts but aren't. We have temporarily moved the data store to a NAS as a workaround but really need a long term solution.

Are you sure it isn't a client issue? I have Sage Line 50 (2010) which has been running smoothly with only ops lock disabled for the past 4 years.  We have 2/3 users.  You should probably run wireshark to see why/where the packets are being lost.

Has anybody got a working smb.conf for a Sage shared data drive under 7.5.1 ? It would appear our highly tuned version from the old install needs a complete revision.  Change in the oplocks directives ?

Maybe post your smb.conf for us to have a look at?

[d6hq]

Thanks byte - but I don't think its the client(s) as they connect to the files on the nas with no problem. We had it all working (for 2-3 years like you) until we moved the server to new hardware and "upgraded" from 7.4.x to 7.5.1 as part of the affa.

Extract of smb.conf

[global]

add machine script = /sbin/e-smith/signal-event machine-account-create '%u'
bind interfaces only = no
case sensitive = no
deadtime = 10080
display charset = ISO8859-1
dns proxy = no
domain logons = yes
domain master = yes
dos charset = 850
encrypt passwords = yes
guest account = public
guest ok = no
hosts allow = 127.0.0.1 192.168.X.0/255.255.255.0
interfaces = 127.0.0.1 192.168.X.X/255.255.255.0
log file = /var/log/samba/log.%m
logon drive = Z:
logon path =
logon script = netlogon.bat
map to guest = never
max log size = 50
name resolve order = wins lmhosts bcast
netbios name = servername
oplocks = true
kernel oplocks = true
level2 oplocks = true
os level = 65
passdb backend = smbpasswd:/etc/samba/smbpasswd
pid directory = /var/run
preferred master = yes
preserve case = yes
security = user
server string = SME Server
short preserve case = yes
smb passwd file = /etc/samba/smbpasswd
smb ports = 139
socket options = TCP_NODELAY
strict locking = no
unix charset = UTF8
unix password sync = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*
check password script = /sbin/e-smith/samba_check_password
unix extensions = no
wins support = yes
workgroup = theworkgroup
printcap name = /etc/printcap
load printers = yes
printing = lprng
print command = /usr/bin/lpr -b -h -r -P%p %s



[sagedata]
browseable = no
force user = admin
force group = accounts
valid users = @groupname, @Groupname, user1, user2
comment = Accounts Data
path = /home/e-smith/files/ibays/sagedata/files
read only = no
writable = yes
printable = no
inherit permissions = yes
create mode = 0660

[byte]

[sagedata]
browseable = no
force user = admin
force group = accounts
valid users = @groupname, @Groupname, user1, user2
comment = Accounts Data
path = /home/e-smith/files/ibays/sagedata/files
read only = no
writable = yes
printable = no
inherit permissions = yes
create mode = 0660

Their appears to be quite a few custom parameters added like "valid users", "force user", etc.  What does:

Code: [Select]

db accounts show sagedata
show?

Do you have any shared folder contrib or other installed to further modify ibays?

[d6hq]

No unusual contribs installed

db accounts show sagedata

sagedata=ibay
    CgiBin=disabled
    Gid=5020
    Group=accounts
    Name=Accounts Data
    PasswordSet=no
    PublicAccess=none
    Uid=5020
    UserAccess=wr-group-rd-group


the force user stuff may be a hangover from a previous hardware move which did not use affa - we had issues where the files were written as admin.user and not accessible to others in the group - EDIT this is where the user uses Sage to "store" documents in things like the Debtor chasing modules - they couldn't be viewed by other Sage users

[byte]

Can you also run:

Code: [Select]

/sbin/e-smith/audittools/templates
Why have you actually added these parameters?

browseable = no
force user = admin
force group = accounts
valid users = @groupname, @Groupname, user1, user2

How did you add these in the first place? If you can remove them and get the smb.conf to the basic out of the box then you will find a better chance of narrowing down your problem.  FTR, here is mine:

Code: [Select]

[sage]
comment = Sage Data


path = /home/e-smith/files/ibays/sage/files
read only = no
writable = yes
printable = no
inherit permissions = yes
create mode = 0660




oplocks = no
level2 oplocks = no

[d6hq]

Thanks byte.

Delving into the far recesses of my onboard RAM I seem to recall that the force users and valid users stuff was added by a colleague when the customer started to use the debtor chasing part of Sage and was "storing" word files etc against the customer which were getting the wrong permissions but I might be wrong.

We still have the "old" server to play with so we will do just that. May be a few days before I report back.

[byte]

Delving into the far recesses of my onboard RAM I seem to recall that the force users and valid users stuff was added by a colleague when the customer started to use the debtor chasing part of Sage and was "storing" word files etc against the customer which were getting the wrong permissions but I might be wrong.

We don't use that area of sage yet but you would need to look at Veto oplock, see http://oreilly.com/catalog/samba/chapter/book/ch05_05.html

[brianr]

I can also report we have Sage line 50 working on fully up to date 7.5.1, shared between 3-5 users.  Has worked for years. through all updates

[d6hq]

Thanks all. Issue is fixed.
Turned out to be a networking issue after all. Deliberately didn't say so at the outset (it would have confused the issue) but the box in question is a bit esoteric running a cut down Centos 5 as a host OS on which we have two VM's - 1) SME7.5.1 as Domain Controller / Samba and 2) another Centos running IBM Lotus Domino 8.5.2. The SME installer had not recognised the bridged gigabit card correctly and was throttling the transfer rate. The Centos machines - host & client - had both recognised it correctly which was why we didn't initially think it was a network issue. We had moved the SME from a real machine and as described above had affa'd to latest release level which is why we thought it was a Samba issue.

[cactus]

Turned out to be a networking issue after all. Deliberately didn't say so at the outset (it would have confused the issue) but the box in question is a bit esoteric

Good you were able to resolve your issues, but next time please do tell all details, as it might have turned a few people to actually guide you to your actual point of failure. There is large pool of knowledge in these forums.

[d6hq]

Yes Cactus we are well aware of the pool of knowledge but sometimes it is best to deal with one possible cause at a time and eliminate it if necessary. You will see that our smb.conf is non standard and it would have been easily possible for an upgrade of Samba to have been the cause. However, the fact that everyone said "no issue with Samba" caused us to rule Samba out.

We were already looking at the VM hardware as a possible problem and you will be pleased to hear that the "fix" to the VM network card issue, once we had identified it as such, came from a search of the forums.

I fear that if I had posted the nature of the hardware at the outset we may have been pointed down numerous dead ends but I do take your point.