Keine Freigaben mehr nach Upgrade von 4.2-4 auf 4.3-1

german
join
samba4
ucs-4-3

#1

Hallo Freunde,

gestern führte ich das Upgrade von 4.2-4 auf 4.3-1 auf einem Master-Server und einem Member-Server aus. Der Master-Server funktioniert so wie erwartet, allerdings ist kein Zugriff mehr auf die Netzwerkfreigaben (nur Share) des Member-Servers möglich.

Die Freigaben werden nicht einmal mehr in der Netzwerkumgebung der MS-Clients angezeigt.

Leider laufen auch die Join-Skripte nicht durch und werden mit Fehlermeldung gespiekt.

univention-run-join-scripts started
So 22. Jul 14:41:44 CEST 2018

RUNNING 96univention-samba4.inst
2018-07-22 14:41:44.352220795+02:00 (in joinscript_init)
Not updating samba4/role
Restarting univention-directory-listener (via systemctl): univention-directory-listener.service.
Multifile: /etc/samba/smb.conf
Object exists: cn=Builtin,dc=xxxxx-yyyyy,dc=intranet
WARNING: cannot append cn=DC Backup Hosts,cn=groups,dc=xxxxx-yyyyy,dc=intranet to nestedGroup, value exists
No modification: cn=Enterprise Domain Controllers,cn=groups,dc=xxxxx-yyyyy,dc=intranet
WARNING: cannot append cn=fileserver,cn=memberserver,cn=computers,dc=xxxxx-yyyyy,dc=intranet to hosts, value exists
No modification: cn=Enterprise Domain Controllers,cn=groups,dc=xxxxx-yyyyy,dc=intranet
Not updating windows/wins-support
Join against S4 Connector server: ucsserver
ERROR: Invalid IP address ‘ucsserver.xxxxx-yyyyy.intranet’!
Samba currently not available on S4 Connector server ucsserver.
Make sure the server is online or if this server is no longer in use,
please completely remove the server object from the domain.
ERROR: Invalid IP address ‘xxxxx-yyyyy.intranet’!
ERROR: Invalid IP address ‘ucsserver.xxxxx-yyyyy.intranet’!
Failed to join the domain.
EXITCODE=1
RUNNING 98univention-samba4-dns.inst
2018-07-22 14:42:00.857300931+02:00 (in joinscript_init)
Samba4 backend database not available yet, exiting joinscript 98univention-samba4-dns.
EXITCODE=1

Mit den Fehlermeldungen begab ich mich auf die Suche und fand folgendes heraus:

root@fileserver:~# samba-tool dns query 192.168.0.254 xxxxx-yyyyy.intranet @ ALL -U Administrator
Password for [XXXXX-YYYYY\Administrator]:
Name=, Records=3, Children=0
SOA: serial=2, refresh=900, retry=600, expire=86400, minttl=3600, ns=ucsserver.xxxxx-yyyyy.intranet., email=hostmaster.xxxxx-yyyyy.intranet. (flags=600000f0, serial=2, ttl=3600)
NS: ucsserver.xxxxx-yyyyy.intranet. (flags=600000f0, serial=1, ttl=900)
A: 192.168.0.34 (flags=600000f0, serial=1, ttl=900)
Name=_msdcs, Records=0, Children=0
Name=_sites, Records=0, Children=1
Name=_tcp, Records=0, Children=4
Name=_udp, Records=0, Children=2
Name=DomainDnsZones, Records=0, Children=2
Name=ForestDnsZones, Records=0, Children=2
Name=ucsserver, Records=1, Children=0
A: 192.168.0.34 (flags=f0, serial=2, ttl=900)

Die IP-Adresse passte also schonmal nicht (sollte eigentlich 192.168.0.254 lauten), ein Gerät mit “192.168.0.34” habe ich hier auch gar nicht im Netz.

Die Änderung führte ich mit folgendem Befehl aus.

samba-tool dns update 192.168.0.254 xxxxx-yyyyy.intranet ucsserver A 192.168.0.34 192.168.0.254 -U Administrator

root@fileserver:~# samba-tool dns query 192.168.0.254 xxxxx-yyyyy.intranet @ ALL -U Administrator
Password for [XXXXX-YYYYY\Administrator]:
Name=, Records=3, Children=0
SOA: serial=2, refresh=900, retry=600, expire=86400, minttl=3600, ns=ucsserver.xxxxx-yyyyy.intranet., email=hostmaster.xxxxx-yyyyy.intranet. (flags=600000f0, serial=2, ttl=3600)
NS: ucsserver.xxxxx-yyyyy.intranet. (flags=600000f0, serial=1, ttl=900)
A: 192.168.0.34 (flags=600000f0, serial=1, ttl=900)
Name=_msdcs, Records=0, Children=0
Name=_sites, Records=0, Children=1
Name=_tcp, Records=0, Children=4
Name=_udp, Records=0, Children=2
Name=DomainDnsZones, Records=0, Children=2
Name=ForestDnsZones, Records=0, Children=2
Name=ucsserver, Records=1, Children=0
A: 192.168.0.254 (flags=f0, serial=2, ttl=900)

Es änderte sich also nur der untere Eintrag der IP-Adresse.

Die Join-Scripte laufen noch immer nicht durch und ich habe leider keine Freigaben im Netz.

Was kann ich noch tun um der Sache Herr zu werden?

Ich danke im Vorwege.

Mfg,
MichaelB


#2

Hallo,

du hast geschrieben, das du “gestern” versucht hast, das UpDate durchzuführen.

Das Datum des Join-Befehls sagt aber “heute”.
Passt evtl. Datum und Uhrzeit beim Member nicht ?

Nur so eine Vermutung.

Gruß,
O. Bertgen


#3

Hallo Herr Bertgen,

Sie haben Recht, ist aber das Log eines weiteren Versuches von gestern.
Die Zeiten beider Systeme sind gleich, kann also als Möglichkeit ausgeschlossen werden.

Aktuell ist so, dass ich nicht einmal die Freigaben ermitteln kann (war gestern auch schon so).

root@ucsserver:~# smbclient -L //fileserver
Connection to fileserver failed (Error NT_STATUS_CONNECTION_REFUSED)

Mfg,
Michael


#4

Huhu,

“connection refused” bedeutet entweder, dass auf dem Port kein Dienst lauscht (aka dass der smbd nicht läuft), oder dass eine Firewall die Verbindung mit REJECT verhindert.

Was kommt denn als Ausgabe, wenn Sie auf fileserver die folgenden zwei Befehle ausführen:

  • smbstatus
  • smbclient -NL //fileserver

m.


#5

Hallo Herr Bunkus,

das Thema Firwall können wir auch ausklammern, auf beiden Systemen hatte ich sie bereits gestoppt.
Das änderte leider auch nichts.

Die Ausgaben lauten wie folgt:

root@fileserver:~# smbstatus

Samba version 4.7.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing             
----------------------------------------------------------------------------------------------------------------------------------------

Service      pid     Machine       Connected at                     Encryption   Signing
---------------------------------------------------------------------------------------------

No locked files

root@fileserver:~# smbclient -NL //fileserver
Connection to fileserver failed (Error NT_STATUS_UNSUCCESSFUL)

Und ja, der Dienst smbd läuft nicht, lässt sich aber auch nicht starten.

root@fileserver:~# ps axu | grep smbd
root     10627  0.0  0.0  14320   944 pts/0    S+   21:33   0:00 grep smbd

root@fileserver:~# service smbd start
Failed to start smbd.service: Unit smbd.service is masked.

root@fileserver:~# service smbd status
● smbd.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead) since Sun 2018-07-22 00:28:43 CEST; 1 day 21h ago
      CPU: 471ms

Jul 22 00:20:00 fileserver systemd[1]: Starting LSB: Samba SMB/CIFS daemon (smbd)...
Jul 22 00:20:03 fileserver smbd[654]: Starting SMB/CIFS daemon: smbd.
Jul 22 00:20:03 fileserver systemd[1]: Started LSB: Samba SMB/CIFS daemon (smbd).
Jul 22 00:28:42 fileserver systemd[1]: Stopping LSB: Samba SMB/CIFS daemon (smbd)...
Jul 22 00:28:43 fileserver smbd[2166]: Stopping SMB/CIFS daemon: smbd.
Jul 22 00:28:43 fileserver systemd[1]: Stopped LSB: Samba SMB/CIFS daemon (smbd).

Einzig der nmbd lies sich starten.

Was bedeutet das wenn ein Dienst maskiert ist und was hat das ausgelöst?
P.S. Ich habe bisher gedacht das das was mit dem Join-Skript zu tun hatte.

Mfg,
Michael


#6

Huhu,

die Ausgabe von smbstatus belegt, dass der smbd-Daemon durchaus läuft.

Falscher Dienst. Der Dienst für den AD-DC-Samba ist samba-ad-dc.service, nicht smbd.service (der ist nur für Samba-AD-Member-Server). Ich sprach vorhin über den smbd-Daemon, nicht den smbd.service-Dienst — der smbd-Daemon wird von beiden Diensten gestartet, aber halt mit unterschiedlichen Optionen.

Was sagt denn die Logdatei /var/log/samba/log.smbd, wenn Sie das smbclient -NL fileserver versuchen?

Und was ergeben ip a und host fileserver?

Was es bedeutet: siehe man systemctl; was es ausgelöst hat: die Installation vom Samba im AD-DC-Modus (siehe oben).

m.


#7

Hallo Herr Bunkus,

Aber es geht doch um einen Memberserver.

Die Datei ist vollkommen leer, sh:

root@fileserver:~# ls -lh /var/log/samba/log.smbd*
-rw-r----- 1 root adm    0 Jul 22 06:27 /var/log/samba/log.smbd
-rw-r----- 1 root adm 1,7K Jul 22 00:20 /var/log/samba/log.smbd.1

Einzig die Datei /var/log/samba/log.smbd.1 enthält folgendes.

[2018/07/21 23:56:52.781245,  0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'smbd' finished starting up and ready to serve connections
[2018/07/22 00:20:03.745973,  1, pid=687] ../source3/profile/profile_dummy.c:30(set_profile_level)
  INFO: Profiling support unavailable in this build.
[2018/07/22 00:20:04.444862,  0, pid=726] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'smbd' finished starting up and ready to serve connections
[2018/07/22 00:20:04.483775,  1, pid=726] ../source3/printing/printer_list.c:234(printer_list_get_last_refresh)
  Failed to fetch record!
root@fileserver:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.253/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe5c:5cb1/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:06:c1:2d:47 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever

root@fileserver:~# host fileserver
fileserver.xxxxx-yyyyy.intranet has address 192.168.0.253

Mfg,
Michael


#8

Ups :slight_smile: Ja richtig.

Dann ist smbd.service in der Tat der richtige Dienst.

Und mir fällt gerade auf, dass smbstatus die von Ihnen gezeigte Ausgabe auch dann liefert, wenn der smbd gar nicht läuft.

Zeigen Sie mir vorsichtshalber bitte noch mal den Paketstatus aller Samba-Pakete:

dpkg -l | grep samba

Die können den Dienst versuchen, wieder in Betrieb zu nehmen, indem Sie ihn zuerst entmaskieren (wie auch immer man das übersetzen möchte) und anschließend zu starten versuchen:

systemctl unmask smbd.service
systemctl start smbd.service
systemctl status smbd.service

Gruß
mosu

PS: Wenn Sie Inhalte von der Befehlszeile oder aus Logdateien hier her übernehmen, dann nutzen Sie bitte nicht die Kommentar-Syntax, um sie zu kennzeichnen (also nicht einfach > vor jede Zeile), sondern schließen Sie den Block in zwei Zeilen ein, die nur aus drei Backticks bestehen. So ungefähr:

```
Kopierter Text kommt
hier hin
```

Das hat gleich zwei große Vorteile: es ist einfacher einzugeben, und (wichtiger) es sorgt dafür, dass sämtliche Markdown-Sonderzeichen eben nicht als Markdown interpretiert sondern verbatim ausgegeben werden. Mehr dazu in der Formatierungs-Anleitung (dort sind das »Code Blocks«). Danke!


#9

N’Abend,

anbei die Ausgabe:

root@fileserver:~# dpkg -l | grep samba
ii  python-samba                                        2:4.7.5-1A~4.3.0.201806181700                    amd64        Python bindings for Samba
ii  samba                                               2:4.7.5-1A~4.3.0.201806181700                    amd64        SMB/CIFS file, print, and login server for Unix
ii  samba-common                                        2:4.7.5-1A~4.3.0.201806181700                    all          common files used by both the Samba server and client
ii  samba-common-bin                                    2:4.7.5-1A~4.3.0.201806181700                    amd64        Samba common files used by both the server and the client
ii  samba-dsdb-modules                                  2:4.7.5-1A~4.3.0.201806181700                    amd64        Samba Directory Services Database
ii  samba-libs:amd64                                    2:4.7.5-1A~4.3.0.201806181700                    amd64        Samba core libraries
ii  samba-vfs-modules                                   2:4.7.5-1A~4.3.0.201806181700                    amd64        Samba Virtual FileSystem plugins
ii  univention-nagios-samba                             3.0.0-1A~4.3.0.201712120054                      amd64        nagios plugin for UCS samba
rc  univention-samba                                    12.0.1-5A~4.3.0.201806201013                     all          UCS - Samba domain controller
ii  univention-samba-local-config                       12.0.1-5A~4.3.0.201806201013                     all          UCS - UCR Extensions for configuration of local shares
ii  univention-samba4                                   7.0.2-17A~4.3.0.201805251509                     amd64        UCS - Samba4 integration package
ii  univention-samba4-sysvol-sync                       7.0.2-17A~4.3.0.201805251509                     all          UCS - Samba4 sysvol synchronization

Starten des Dienstes klappte anstandslos, wie in der Ausgabe zu erkennen ist.

root@fileserver:~# systemctl status smbd.service
● smbd.service - LSB: Samba SMB/CIFS daemon (smbd)
   Loaded: loaded (/etc/init.d/smbd; generated; vendor preset: enabled)
   Active: active (exited) since Tue 2018-07-24 20:01:18 CEST; 39min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 30271 ExecStart=/etc/init.d/smbd start (code=exited, status=0/SUCCESS)
      CPU: 204ms

Jul 24 20:01:17 fileserver systemd[1]: Starting LSB: Samba SMB/CIFS daemon (smbd)...
Jul 24 20:01:18 fileserver smbd[30271]: smbd disabled by ucr var samba/autostart=no
Jul 24 20:01:18 fileserver systemd[1]: Started LSB: Samba SMB/CIFS daemon (smbd).

Allerdings ist trotzdem nichts bei den Prozessen zu finden.

root@fileserver:~# netstat -tulpen | egrep "smb|samba"
root@fileserver:~# 
root@fileserver:~# ps axu | egrep "smb|samba"
root      4151  0.0  0.0  14320  1024 pts/0    S+   20:45   0:00 grep -E smb|samba
root@fileserver:~#

Mfg,
Michael


#10

Huhu,

die Pakete univention-samba4 und univention-samba4-sysvol-sync sind eigentlich für AD DCs und nicht für AD Memberserver gedacht. Für Memberserver ist univention-samba da. Sieht für mich nach einer irgendwie vergeigten Installation aus. Also:

  1. Pakete univention-samba4 und univention-samba4-sysvol-sync entfernen,
  2. Paket univention-server-member installieren, sofern nicht installiert (wenn es wirklich ein UCS Memberserver ist, dann muss das hier installiert sein; siehe ucr get server/role)
  3. Sicherstellen, dass die App samba-memberserver installiert ist (so heißt sie in der Ausgabe von univention-app info; im App Center sowas wie »Windows-kompatibler Memberserver«)
  4. Paket univention-samba installieren,
  5. Konfiguration neu bauen: ucr commit
  6. Dienst smbd.service starten (oder sicherheitshalber ein Reboot)

Bevor Sie das alles machen, zeigen Sie mir lieber noch die Ausgabe der folgenden Befehle:

dpkg -l | grep univention-server
ucr get server/role
univention-app info

Gruß
mosu


#11

Guten Abend,

mmmhhhh, merkwürdig.

Hier zuerst die Ausgaben:

root@fileserver:~# dpkg -l | grep univention-server
ii  univention-server-member                            13.0.0-3A~4.3.0.201803161509                     all          UCS - member server
root@fileserver:~# ucr get server/role
memberserver
root@fileserver:~# univention-app info
UCS: 4.3-1 errata151
Installed: pkgdb=11.0
Upgradable: 

Ist alles so wie erwartet?
Mfg,
Michael


#12

Nein, die App ist nicht installiert (wobei das Fehlerbild nun Sinn ergibt). Installieren Sie einfach die App »Windows-kompatibler Memberserver« aus dem App Center. Anschließend sollte es schon funktionieren.


#13

Hallo Herr Bunkus,

perfekt, alles läuft wieder so wie erwartet, danke für Ihre Unterstützung.

Mfg,
Michael