Since upgrading two machines to LEAP 15, their shares no longer appear on my Mac unless I restart smb on those machines. I suspect machines are fighting to see who is the samba master. How do I make sure that one of my LEAP machines is always the Master?
In '/etc/samba/smb.conf" the default value of the Global parameter “domain master” (“domain master = auto”) should take care of that.
Please check everything in the “domain master” section of the “smb.conf” man page for anything which may be causing the Samba Servers to provoke a Domain Master conflict with another or, possibly, with Redmond Domain Master machines on the affected network segment.
[HR][/HR]BTW:
The Apple Mac machines are UNIX® and, therefore, they understand NFS extremely well – Linux is a *NIX and, therefore, Linux machines also understand NFS very well. A suggestion is, forget the “Redmond protocol” for the access from Mac to Linux (and vice versa) and, use the UNIX® and Linux NFS protocol to provide Network File System access between the machines.
The upgrade dumped all the configuration to make my machine the master. I recovered the correct commands from the backup.
However, in LEAP 15, if I leave this line
name resolve order = wins lmhosts hosts bcast
in the global section, smb will not start. What has changed to cause this?
[global]
workgroup = JARPCS
netbios name = JARDELL
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = No
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
domain logons = Yes
domain master = Yes
local master = Yes
preferred master = Yes
security = user
username map = /etc/samba/smbusers
os level = 255
remote announce = 192.168.1.255/SIMPLEs
wins support = Yes
# name resolve order = wins lmhosts hosts bcast
Generally speaking,
Nowadays those should be disabled because they are relics of the very old NetBIOS Name resolution method which was the standard in NT4 Domains (up to approx 2003 and then supported but deprecated since). To support this type of name resolution you have to deploy a WINS server, configure lmhosts files or rely on broadcasts, all which would generally be extra work for a SysAdmin.
Today, Domain name resolution even in SAMBA and Active Directory Domains standardize on the same Hostname resolution that the Internet uses which relies on DNS servers and the Hosts file, both which are commonly found on all machines today and already used for Internet services.
TSU
Currently, despite all the parameters available for ‘smb.conf’, Samba seems to run better with a minimal amount of information in ‘smb.conf’ – the following configuration uses the local TDB user password storage:
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
[global]
interfaces = 127.0.0.1 192.xxx.yyy.0/24 eth0
workgroup = WWW
netbios name = ZZZ
server string = ""
passdb backend = tdbsam
map to guest = Bad User
idmap config * : backend = tdb
idmap config * : range = 1000000-2000000
[homes]
[profiles]
[users]
[groups]
All other parameter values are the default values.
[HR][/HR]I have to admit that, I’ve given up attempting to export the Linux printer queues to the Redmond boxes via Samba – our Redmond boxes now use “http://hostname:631/printers/printer_name” to access the Linux CUPS printer queues.
Your Apple machines should also be using CUPS (owned by Apple) to access any Linux printer queues …
my LEAP 15 smb is still not staying on as master. Somehow, I think my router (Linksys EA9500) is overriding it. There are no router settings to change/enable/disable WINS serving.
I figured this out. The upgrade to Leap 15 turned off nmbd. It seems to me that the upgrade process should keep running services running…
After I turn on nmb, smb stays connected and is infinitely faster.
Maybe an openSUSE Bug Report to flag this behaviour might be a good idea …