Samba 4.5 probleme nach upgrade von Ubuntu Server LTS...

[robert]

Hallo,

ich habe jetzt schon alles im Netz durchsucht, aber finde keine Lösung. Vielleicht kann mir hier jemand einen Hinweis geben.

Also, ich habe einen Internet-Server mit Ubuntu Server 16.04 LTS (mit Samba 4.3.x) laufen und einen Home-Server der bisher auch mit Ubuntu-Server 16.06 LTS lief. Auf dem Home-Server habe ich ein Upgrade auf 18.04 LTS gemacht, auf dem jetzt Samba 4.5.x läuft. Ich verbinde den Home-Server über VPN mit dem Internet-Server, lief und läuft ohne Probleme. Über VPN verbinde ich dann den Internet-Server zum Home-Server mit CIFS (NFS gab zu oft Verbindungs-Probleme, etc. pp.) um z.B. auf bestimmte Daten für den Server zuzugreifen oder BackUps zu machen.

So, bisher lief alles ohne Problme (Samba 4.3 -> 4.3). Aber seit Ubuntu 18.04 Samba 4.5 drauf hat, gibt es nur noch Probleme. Ich konnte im LAN schon Probleme mit Windows 10 Clients beheben, aber nun bekomme ich beim Verbinden von Samba 4.3 Client zum Samba 4.5 Server immer folgende Fehlermeldung.

mount error(112): Host is down

bzw.

protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Ich habe es beim Client mit der Mount-Option vers=1.0 bis 3.02 versucht, bzw. mit smbclient option -m SMB2 bis SMB3.02, aber nichts funktioniert. Immer der gleiche Fehler, obwohl über VPN alles sonstigen Verbindungen ohne Probleme funktionieren.

Hier mal die globale smb.conf vom Server.

# Global parameters
[global]
	server string = fulla 
	netbios name = fulla
	workgroup = MHIMC

	server role = standalone server
	os level = 20
	security = USER

#	min protocol = SMB3

#	interfaces = 192.168.10.200
	interfaces = tun0 192.168.10.200/24
	bind interfaces only = yes

	hosts deny = all
	hosts allow = 192.168.10. localhost

	socket options = SO_KEEPALIVE TCP_NODELAY
	keepalive = 15
	dns proxy = no

	available = no
	browseable = no

	unix password sync = Yes
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	passwd program = /usr/bin/passwd %u
	pam password change = Yes
	obey pam restrictions = Yes
	usershare allow guests = Yes
	map to guest = Bad User
	panic action = /usr/share/samba/panic-action %d
	idmap config * : backend = tdb

	unix extensions = yes
	hide files = /desktop.ini/ntuser.ini/NTUSER.*/Thumbs.db/Desktop.ini/
	write raw = no
	read raw = no

	printing = bsd
	printcap name = /dev/null

	log file = /var/log/samba/log.%m
	max log size = 1024

[smb]
	path = /srv/smb
	comment = smb xchange
	browseable = no
	available = yes
	writable = yes
	force user = robby
	valid users = robby
	create mode = 0666
	directory mode = 0777

Beim Client (Samba 4.3) steht folgendes in der fstab:

//192.168.10.200/smb	/srv/smb	cifs	defaults,rw,user,users,_netdev,soft,intr,iocharset=utf8,file_mode=0664,dir_mode=0775,vers=2.0,credentials=/etc/.smbcredentials	0 0

192.168.10.200 ist der Samba Server über VPN (198.168.10.0/24).

Ich habe einfach keine Idee mehr, was da auf einmal mit Samba 4.5.x falsch läuft. Es scheint, als würde Samba mit jeder neuen Version schlechter werden und weniger funktionieren.

Bin für jeden Hinweis dankbar. Falls noch Informationen gebraucht werden, bitte sagen!

Wenn nichts klappt, werde ich wohl oder übel den Internet-Server auch auf Ubuntu 18.04 LTS upgraden müssen, da Clients damit wohl keine Probleme haben. Was auch immer die bei Samba gemacht haben zwischen 4.3.x zu 4.5.x, es scheint alles nur schlimmer zu machen.
Und ich würde ungern den Internet-Server im Moment upgraden.

Gruß
Robert

[atomical]

was bezweckt

	available = no

OT:

für mal schnell eine Datei kopieren nutze ich SSHFS mit dem MC

für Backups via VPN nutze ich rsync mit rsyncd auf dem Zielrechner

[robert]

Ich habe das Problem inzwischen gefunden!
Es saß vor dem Monitor und sah den Wald vor lauter Bäumen nicht.
Ich hatte vergessen, dass der I-Net Server versucht sich von seiner IP zu verbinden und nicht vom VPN SubNet. Und diese hatte ich im Samba Server nicht frei gegeben. :-)

Und ja... ich habe auch mit einem Script und rsync meine BackUps gemacht, aber wie gesagt, es gibt über VPN oft Probleme mit NFS. Z.B. beim System-Start oder Reboot hängt nfs (dank systemd, etc. pp.) und das war mir langsam zu blöd.
Außerdem musste ich noch eine andere CIFS Freigabe auf den Server bringen und NFS kann keine anderen Netzwerk-Mounts freigeben... :-(
NFS hat zu viele Nachteile...

[atomical]

... rsync meine BackUps gemacht, aber wie gesagt, es gibt über VPN oft Probleme mit NFS. ...

... das meinte ich ja - wenn du auf der Ziel-Seite RSync als Dienst laufen hast (Mittelweg via SSH geht wohl auch noch), brauchst du gar kein Netzwerkdateisystem - weder NFS noch SMB ...