Kann jemand mit unten stehendem kernel Panic Report etwas anfangen? Wenn weitere Information erforderlich ist, lasst es mich gerne wissen!

Anonymous UUID: FC3707F5-715B-51BC-C1FA-E4CE05C19E2C

Fri Jun 7 15:37:48 2019

*** Panic Report ***
panic(cpu 1 caller 0xffffff801e8db92d): Kernel trap at 0x0000000000000000, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x0000000000000000, CR3: 0x00000000224d8000, CR4: 0x00000000001626e0
RAX: 0xffffff8031f605a0, RBX: 0x000000000000007e, RCX: 0xffffff8031f605a0, RDX: 0x0000000000000000
RSP: 0xffffff81218ebb78, RBP: 0xffffff81218ebbc0, RSI: 0x0000000000001002, RDI: 0xffffff8031da6000
R8: 0xffffff81218ebb60, R9: 0x0000000000000001, R10: 0x0000000000000004, R11: 0xffffff804dc33c48
R12: 0xffffff8031fbd000, R13: 0x0000000000001002, R14: 0xffffff8123655e40, R15: 0x0000000000000000
RFL: 0x0000000000010216, RIP: 0x0000000000000000, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000000, Error code: 0x0000000000000010, Fault CPU: 0x1, PL: 0, VF: 1

Backtrace (CPU 1), Frame : Return Address
0xffffff81218eb640 : 0xffffff801e7aea2d
0xffffff81218eb690 : 0xffffff801e8e9e95
0xffffff81218eb6d0 : 0xffffff801e8db70a
0xffffff81218eb740 : 0xffffff801e75bb40
0xffffff81218eb760 : 0xffffff801e7ae447
0xffffff81218eb880 : 0xffffff801e7ae293
0xffffff81218eb8f0 : 0xffffff801e8db92d
0xffffff81218eba60 : 0xffffff801e75bb40
0xffffff81218eba80 : 0x0
0xffffff81218ebbc0 : 0xffffff7fa01dfa59
0xffffff81218ebd70 : 0xffffff7fa01abd0a
0xffffff81218ebe30 : 0xffffff7fa032ff3f
0xffffff81218ebe90 : 0xffffff7fa00e4ed8
0xffffff81218ebed0 : 0xffffff801ee5827c
0xffffff81218ebf30 : 0xffffff801ee56362
0xffffff81218ebf70 : 0xffffff801ee558bc
0xffffff81218ebfa0 : 0xffffff801e75b0ce
Kernel Extensions in backtrace:
com.apple.driver.AirPort.BrcmNIC(1400.1.1)[0F1637EA-51B0-3A81-9433-956A19427984]@0xffffff7fa00c20000xffffff7fa087dfff
dependency: com.apple.driver.corecapture(1.0.4)[B6895620-1670-31C3-A1E4-3CDFD34022C4]@0xffffff7f9ff7f000
dependency: com.apple.driver.mDNSOffloadUserClient(1.0.1b8)[D6757506-88E6-3535-8813-F85DC0AD3D23]@0xffffff7f9ffb2000
dependency: com.apple.iokit.IO80211Family(1200.12.2)[A879B51A-4562-3B95-B6C3-A2472B508F2F]@0xffffff7f9ffba000
dependency: com.apple.iokit.IOPCIFamily(2.9)[CC6A465F-5A24-304D-B9DF-8C27819CC214]@0xffffff7f9f095000
dependency: com.apple.iokit.IONetworkingFamily(3.4)[633B919E-8F93-3ED4-9A29-894AB1E79D29]@0xffffff7f9f3b2000

BSD process name corresponding to current thread: kernel_task

Mac OS version:
18F132

Kernel version:
Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64
Kernel UUID: 7C8BB636-E593-3CE4-8528-9BD24A688851
Kernel slide: 0x000000001e400000
Kernel text base: 0xffffff801e600000
__HIB text base: 0xffffff801e500000
System model name: Macmini7,1 (Mac-35C5E08120C7EEAF)

System uptime in nanoseconds: 2080941156898
last loaded kext at 250077093709: com.apple.filesystems.msdosfs 1.10 (addr 0xffffff7fa1de4000, size 69632)
last unloaded kext at 459190734188: com.apple.filesystems.msdosfs 1.10 (addr 0xffffff7fa1de4000, size 61440)
loaded kexts:
com.apple.filesystems.smbfs 3.3.2
com.apple.driver.AudioAUUC 1.70
com.apple.fileutil 20.036.15
...
...
...
com.apple.driver.AppleSMC 3.1.9
com.apple.iokit.IOPCIFamily 2.9
com.apple.iokit.IOACPIFamily 1.4
com.apple.kec.pthread 1
com.apple.kec.Libm 1
com.apple.kec.corecrypto 1.0

EOF
Model: Macmini7,1, BootROM 242.0.0.0.0, 2 processors, Intel Core i5, 2,6 GHz, 8 GB, SMC 2.24f32
Graphics: kHW_IntelIrisItem, Intel Iris, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x483943434E4E4E424C54414C41522D4E5444
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x483943434E4E4E424C54414C41522D4E5444
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x13B), Broadcom BCM43xx 1.0 (7.77.61.2 AirPortDriverBrcmNIC-1305.8)
Bluetooth: Version 6.0.12f1, 3 services, 27 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: APPLE HDD HTS541010A9E662, 1 TB
USB Device: USB 3.0 Bus
USB Device: IR Receiver
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Hub in Apple Pro Keyboard
USB Device: USB-PS/2 Optical Mouse
USB Device: Apple Pro Keyboard
Thunderbolt Bus: Mac mini, Apple Inc., 26.1

Technischer Fehler in der WLAN-Karte oder deren Treiber.

Super! Danke! Das ging schnell.

Hatte ich schonmal durch defekte SSD. Wollte per File Sharing größere Datenmengen kopieren und schmierte dann immer ab. Fiel erst nicht auf, da der Rechner komischerweise sonst keine Zicken machte, aber FS mochte er gar nicht. Hab daher erst an der falschen Stelle gesucht.

@Brandy: Erzähl mal Näheres! Hatte Dein Rechner dann auch Airport-Probleme "gemeldet"?

Nein, ich hatte das per Ethernet gemacht, weil es so viel war. Der Kopiervorgang endete dann immer mit einem Kernel Panic. Hab dann irgendwann entnervt die Platte aus dem Laptop ausgebaut und in den MacPro eingebaut, um die Daten zu kopieren. Also direkt von Platte zu Platte, oder eher SSD zu SSD. Als das auch im Panic endete, wußte ich, dass es doch wohl kein Bug mit dem File Sharing war.
Aus den Panic Logs bin ich aber damals nicht schlau geworden, jedenfalls konnte ich von da nicht auf die Ursache schließen, leider.

Wenn der Fehler mit der WLAN-Karte zu tun hat, dann ist zu erwarten, dass in
/Library/Logs/CrashReporter/CoreCapture (siehe Konsole)
Berichte erscheinen, die vom Treiber der Broadcom-Karte und vom Framework IO80211Family erzeugt werden. Dabei ist aber auf Datum und Uhrzeit zu achten: "Crash"-Meldungen bezüglich Airport können unter Umständen häufig auftreten, ohne dass es zu einer Kernel-Panic kommt, zum Beispiel durch Verbindungsabbruch oder fehlgeschlagene Authentifizierung.

@Virk
Ist das der umgebaute MacMini mit SSD aus dem anderen Thread ?

@rmayergfx: Ja, der ist es.

Ganz ehrlich, dann verstehe ich nicht, warum du das nicht gleich hier in den Thread mit hineinschreibst.
Sieht wohl doch so aus also würde die verbaute Crucial hier Stress machen. Nimm eine Samsung EVO 970 und mache den Test erneut.

Wenn ich am Mac oder PC Probleme hatte mit SSD dann waren das Crucial....Wenn ich mir die Rezensionen zur P1 bei amazon ansehe scheinen die immer noch recht schnell defekt zu gehen.... Zusätzlich scheinen die Teile auch noch extrem heiß zu werden was nicht besonders gut ist, denn dadurch wird das restliche System mit aufgeheizt.

Den Ordner /Library/Logs/CrashReporter/CoreCapture gibt es auf dem Rechner (noch?) nicht.

Gibt´s hierzu ein Update ? Wie ist der aktuelle Status ? NVME getauscht ?

Nein, es gibt noch nichts wirklich relevantes neues. Der mac mini läuft parallel im noch testweise und ab und zu ist über filesharing kein Zugriff (von meinem Mojave-MBP) mehr möglich. Meinen Rechner "musste" ich sogar manchmal Neustarten, weil der Finder nicht durch mich zur Mitarbeit zu bewegen war. Ich habe noch keine Ahnung, woran das liegt.
(Als server läuft jetzt ein MBP mid 2012, in den ich die ursprüngliche Crucial-SATA-SSD eingebaut habe völlig unauffällig)
Aller Voraussicht nach werde ich nach meinem Urlaub (22 Tage Windsurfen ) eine Samsung NVMe kaufen gehen, aber das bleibt abzuwarten.

10.14.5 update vorher durchgeführt?
damit brach bei mir das netzwerk zusammen.

Tests hatte ich mit 10.14.5 durchgeführt; war nie was anderes drauf.

@hoberger: Gibt es bei Dir etwas Neues? Mit welchem System/Rechner gibst Du aktuell Daten im Netz frei? Über smb oder afp oder beides?

Ja, glaube den Fehler gefunden zu haben:
Ich greife mit 10 High Sierra Clients per SMB auf den 10.14.5 Server zu.
AFP wollte der nicht so recht mit einer SSD die auf APFS formatiert ist, jedenfalls da nur Fehler. Wäre gern zu AFP zurück gegangen.

Parallelversuch mit zweitem Netz zu Hause zeigte mir, dass sich x.5 weigert als Freigabenamen Leerzeichen zu akzeptieren. Also Festplatte heißt z.B. „HD Hoberger“, dann machte bisher OS als Freigabevorschlag dies ergänzt um ein „s“ und den Gerätetyp (Mac Mini) eigenständig so: „HD Hobergers Mac Mini“, nun unter 10.14.5 aber plötzlich alles ohne Freizeichen. Da ich die Pfade erhalten wollte manuell wieder den alten Namen eingegeben und dann geht das Theater los. Gut, brauch man sich nicht wundern werden schlaue Leute sagen, wenn man das einzwängt, aber bei einem Update ändert man einen jahrelang genutzten Freigabenamen ja nicht.
Gibt man manuell einen Pfad z.B. über „verbinde mit Server“ ein, musste man bei SMB eh immer schon das Leerzeichen durch ein „%20“ oder so ersetzen, bzw. das OS hat das eigenständig so aufgelöst. Das scheint nicht mehr zu funktionieren und so stürzt nicht der 10.14.5 Server, sondern alle Clients ab bis zum Netzsteckerziehen.
10.15.3 verdaut das ohne Probleme und damit läuft Dank Time Machine alles wieder. Also kein Leer- oder sonstiges Zeichen in dem HD- und Freigabenamen, dann schnurrt .5 wieder und die 10.13.6er Clients
SMB ist für Apple Talk Veteranen in dieser Hinsicht ein Rückschritt um 25 Jahre.

Also Netzwerkfreigaben mit Leerzeichen oder Sonderzeichen/Umlauten sollten sowieso Tabu sein.
Wenn man unbedingt den Namen der HD oder SSD mit Leerzeichen haben möchte, so ändert man in den Systemeinstellungen unter Sharing einfach den Namen so ab, das hier keine Leerzeichen mehr vorhanden sind.
Das gleiche gilt für etwaige shared Folders. Wer in einem mixed Network mit verschiedenen OS arbeitet spart viel Zeit und Lehrgeld. So etwas kann immer passieren, je nachdem mit welchem OS und welcher Samba Version das Share angesprochen wird.

Recht hast Du. Das weiß ich jetzt auch.

Das Problem ist nur, dass der Mac standardmäßig diese Freigabe selbst!!!! generiert und alte Macuser das auch ziemlich normal finden seit 25 Jahren.

Selbst aus einer harmlosen Festplatte Namens „HDD“ wird dann bis 10.14.3 von MacOS eigenständig ein „HDDs Mac Mini“ als Freigabe generiert!!!
Also ohne dass ein Dummerchen wie ich hier Hand anlegt.

Wieso macht das OS das, wenn es dann selbst damit nicht klarkommt?
Dies zudem in einem reinen macOS Netz, da muss man erstmal drauf kommen.

Windows-User kennen so was ja, aber da würde das Betriebssystem so etwas auch nicht vorschlagen oder eigenständig generieren.

Evtl. habe ich bei meiner Testinstallation mit Mojave als filesharing-server ein ähnliches Problem.
Wo sollen diese Leerzeichen bei smb-Freigaben (..liegt auf APFS) denn nicht auftauchen?
- Im "Systemeinstellungen/Freigaben/Gerätename"?
- Im "Systemeinstellungen/Netzwerk/Weitere Optionen.../WINS/NetBIOS-Name"?
- In jedem Ordner unterhalb der Freigabe selbst?

Habt Ihr noch einen weiteren Tipp?

@hoberger: Wenn Du weitertesten solltest; bei mir stürzt(e) der client auch hoffnungslos ab, sodass ich ihn "neustarten musste". Alternativ stellte ich fest, dass es bei mir auch reichte, den Mojave-Rechner, der die Daten serviert, neu zu starten. Das ging bei mir viel schneller.

Das stimmt so nicht. Du scheinst den Namen des Volumes mit dem Gerätenamen zu verwechseln.

Aus dem Gerätenamen wird der Bonjour-Name (ohne Leerzeichen, mit ".local" am Ende) erzeugt.
Der Gerätename wird außerdem RFC-konform in einen Namen für die DHCP-ID umgewandelt. Je nachdem, welchen Router Du einsetzt, wird dann dieser Name als Namensvorschlag für den DNS-Namen dieses Macs im Netz verwendet.

Es gibt also 4 Namen für jeden Mac, die auf komplizierte Weise voneinander abhängen und für die unterschiedliche Regeln gelten, welche Codierungen eingehalten werden müssen und welche Zeichen zulässig sind.

Das hängt davon ab, was man in das Feld eingibt. Wenn es sich um eine URL handelt oder die Eingabe zu einer URL ergänzt wird, dann sind Leerzeichen natürlich verboten.

Wenn das stimmen würde, wäre das eine Sicherheitslücke, die an Apple gemeldet werden sollte, denn damit wäre ein Local-Denial-of-Service-Angriff möglich. Ich habe aber da meine Zweifel …

Gerätename: bei mir war Plattename und Gerätename ähnlich.
Das geht ja immer zack zack so einen Mac einzurichten, also sorry für die Verwirrung. Danke für den Hinweis auf die vielen Bezeichnungen.

@virk
Also der erste angelegte Nutzer heißt z.B. „Hoberger“, dann wurde unter „Freigaben“ in den Systemeinstellungen vom System bisher immer als Gerätename „Hobergers Mac Mini“ vorgeschlagen, der dann bei allen anderen im Netz auch im Finder so auftaucht. Seit 10.14.5 ist das offenbar anders und macOS erzeugt einen Freigabenamen nur noch ohne Leerzeichen.
Macht man ein Update mit einem alten Gerätenamen mit Leerzeichen, scheint es die Probleme zu geben. Hast Du also da in den Systemeinstelungen einen Gerätenamen mit Leerzeichen, dann kannst Du ihn da einfach ändern.

Also auf den Server unter Sytemeinstelungen einen unkritischen Gerätenamen eingeben und der freigegebene Ordner sollte ebenso einfach sein.

Leider hilft das alles bei der fehlenden Vererbung von Rechten nicht weiter, was unter SMB einfach nicht funzt. Das gute alte AFP - Netzwerkprotokoll funzt wiederum nicht mit einem Server, der auf APFS formatiert wurde, was bei einer SSD aber inzwischen Standard ist.
Journaled soll man laut Apple nicht formatieren, wenn mal APFS formatiert wurde. Kann ich bestätigen,so schon ein Fusion Drive zerschossen.

Also zurück in die Abgründe des Windowsprotokoll gefühlt in die 90er...

Das geht problemlos. Man muss nur die Rechte der Ordner wie gewünscht einstellen, entweder über die Unix-Befehlszeile oder über fremde Programme.

Ich habe weitere Tests parallel laufen. Habe alle Leerzeichen, etc. entfernt. Jetzt meine ich folgendes festgestellt zu haben:
- Wenn ich von Mojave über Ethernet oder airport auf die Freigabe zugreife, kommt irgendwann beim client der beachball. Dann muss ich entweder den client oder den server Neustarten. (Ich kann nicht sagen, dass dieses Leerzeichen-Wegmachen etwas geändert hätte)
- Wenn ich von Sierra (MBP mid 2009) über Ethernet oder airport auf die Freigabe zugreife, kommt es bislang (2h) zu keinem problematischen Verhalten.

Jemand eine Idee, wie ich das weiter einkreisen könnte.

Nachtrag: Besagte 2h lief alles gut, jetzt habe ich gerade versucht mit Mojave die Freigabe über Ethernet zu mounten, sie kam auch, dann wieder abgemeldet, andere Freigabe gemountet, abgemeldet, "problematische"Freigabe gemountet, beachball auf dem Mojave-Rechner und Probleme (Freigabe nicht mehr auswerfbar und auch nicht lesbar) auf dem Sierra-MBP.

Kannst du ein aktuelles Programm empfehlen?

Ich empfehle TinkerTool System; dann brauch' Marcel es nicht zu tun

@ Marcel Bresink
Wir haben hier ein "ähnliches" Problem: Server (aktueller MacMini mit 2TB SSD, nichts manuell eingebaut) unter 10.14.5 und sämtliche Clients unter 10.14.5.
Nun haben wir seit der 10.14.5 das Problem, wenn ein Benutzer einen Ordner anlegt und umbenennt oder verschiebt, crasht die Dateifreigabe vom Server. Dies innert einer Woche bereits dreimal, teilwiese klappt es problemlos.
Einzige Lösung ist anschliessend ein Neustart vom Server (alle anderen Dienste laufen einwandfrei weiter). Die Rechte haben wir mit TinkerTool System richtig vergeben. Ich vermute das es hier ein grundsätzliches Problem geben muss, wie z.B. hier erwähnt wird:
Hast du eine Idee für eine Lösung?

Wo ist da ein "Crash" erwähnt?

Nochmal: Ein Crash wäre eine kritische Sicherheitslücke, die sofort an Apple gemeldet werden sollte. Hast du einen Crash-Report?

Naja, aber warum geht das nicht wie früher direkt übers Betriebssystem.
Bei High Sierra gebe ich im übergeordneten Ordner eine Gruppe vor, die alle lesen und schreiben dürfen. Danach kann da jeder machen was er will und alle Mitglieder der Gruppe konnten alle Ordner/Dateien lesen, ändern oder löschen. Mit Unix Befehlszeilen kenne ich mich nicht aus, ich bin eher Anwender mit etwas Basiswissen.

Das geht problemlos, aber Apple erwartet, dass man dazu die Unix-Befehlszeile nutzt.

macOS enthält 5 verschiedene File Server (für APF, SMB, NFS, WebDAV und SFTP). In einigen davon war tatsächlich früher eine Sonderbehandlung programmiert, die so getan hat, als ob es so etwas wie "Berechtigungen für eine Netzwerkfreigabe" gegeben hätte.

Das widerspricht aber dem Sicherheitskonzept moderner Betriebssysteme, bei dem für jede einzelne Datei und jeden Ordner getrennte Berechtigungen eingestellt werden. Es ist ebenso nicht einzusehen, weshalb es vom verwendeten Netzwerkprotokoll abhängen soll, ob Berechtigungen möglicherweise ignoriert werden. Apple hat diese Sonderbehandlung nun aufgegeben, so wie es seit 2005 (mit der Einführung von ACLs in Mac OS X 10.4 Tiger) eigentlich schon hätte sein sollen. Die Protokolle verhalten sich im Rahmen ihrer jeweiligen Möglichkeiten einheitlich und für Zugriffsrechte bestehen zwischen lokalem und Netzwerkzugriff keine komplizierten Unterschiede mehr.

Danke für die logischen Erklärungen. Auch wenn es nicht schmeckt, scheint zumindest ein Sinn dahinter zu stecken.

Frage nur, wie soll der unbedarfte User wissen, was er wo als Unixbefehl eintippen muss?! Ich wüsste nicht ansatzweise, was da zu tun ist. Befehlszeilen und Mac schließt sich für mich eigentlich aus, da können wir ja gleich auf DOS 1.0 wechseln....

Wie ist das denn bei NAS-Systemen geregelt? Da soll es doch nach wie vor funktionieren, dass man Gruppen anlegt und jedes Mitglied kann anlegen, löschen und ändern und alle anderen in der Gruppe kommen damit klar.

@virk: Bei mir funktioniert Server 10.14.5 nur mit 10.13.6 Clients jetzt wieder. Mojave Clients habe ich (noch) nicht und werde Deine Berichte mit großem Interesse verfolgen, denn ein neuer Mc wird mir ja Deine Konstallation zwangsweise bringen. Auch weil Apple „netterweise“ das Aufspielen älterer Systeme nicht mehr erlaubt

virk, Marcel
Ja, kenne ich. Scheint aber das einzige zu sein. Zumindest ist mir sonst nix bekannt und deswegen wollte ich mal in den Wald horchen ob es noch weitere Alternativen gibt.

BatChmod gibt es noch; ist allerdings wohl nur für POSIX und lange nicht so komfortabel with TinkerTool System.

Apple nat ein Updte rausgebracht, dass auch Fehlerbehebung/Stabilität beim SMB-Protokoll beinhaltet. Unser Fehler? Ich weiß es nicht, rühre den aus ™ wiederhergestellten Server nicht mehr an....

Ich habe dazu in einem Parallelthread was geschrieben; bei mir taucht das Problem seit dem update auf 10.14.6 nicht mehr auf.