PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba 4.5 probleme nach upgrade von Ubuntu Server LTS...



robert
05.05.18, 18:29
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,creden tials=/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
06.05.18, 09:48
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
06.05.18, 15:07
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
07.05.18, 00:36
... 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 ...