Also das ist natürlich jetzt schlecht nachzuvollziehen
Also er lädt, du kommst in den Spawn Screen und musst Respawn drücken?
Oder wie
In welchem Screen musst du denn Respawn drücken?
Scrrebshot wäre sehr hilfreich
Edit: Ok na dann hat sich das ja erledigt
Also deine Server Logs sollten im Hauptverzeichnis liegen, mit ".rpt" endung.
Edit: Oh und bitte Screenshot vom Server Hauptverzeichnis dazu schicken....
Edit2: Achso und schau mal ob du "-noLogs" irgendwo als Startparameter stehen hast, falls ja mach das mal weg
Okay, aber dort sind keine. Erstellt der kein muss man das irgendwo einstellen?
Also wenn er keine erstellt, vermute ich mal wie oben erwähnt, steht als Startparameter irgendwo "-noLogs" drin.
Du startest den Server bestimmt per ".sh" File oder? Dann schick mal den File durch. (Musst du aber als .tar oder.zip hochladen)
Okay ja es steht nirgendswo "-noLogs".
Also einige dinge fallen mir direkt auf,
der File "core" ist an der stelle unlogisch. Den gibt es eig. nur im Altis.Life Ordner.
Und was sehr unschön ist, du nutzt für "@extDB3, @life_server, basic.cfg, server.cfg und core(keine ahnung ob das sinn macht)" Root als ausführendes Element. Das ist bei Linux nicht unbedingt hilfreich, besser wäre du machst alles über den Benutzer "arma" und setzt diesen auf die Sudoers liste
Da der Server als Benutzer "arma" keine dinge vom "Root" ausführen kann
Edit: Setz mal bitte die Berechtigungen von "@extDB3" auf die selben wie die anderen Ordner
Setz aber bitte mal den Ordner "@extDB3" auf "0755" momentan hat er glaube "0777"
Sagt er jetzt was anderes, also wenn du dich verbinden willst?
Falls es nicht klappen sollte schlag ich dir alternativ vor, das du einen Benutzer erstellst zb "altislife" diesem sudoer Rechte gibst und ich mir das ganze mal anschaue. Dazu müsstest du mir natürlich deine Server Daten (IP) sowie das Passwort von dem erstellen Benutzer per PN zukommen lassen.
Das ganze würd ich aber erst heute.... sagen wir mal gegen 14:00 oder 15:00 Uhr machen, denn Schlafen wollte ich heut auch noch
Edit: Und natürlich nebenbei TS, lieber wäre mir aber Discord
Dazu müsstest du mir natürlich deine Server Daten (IP) sowie das Passwort von dem erstellen Benutzer per PN zukommen lassen.
Bitte niemals die Daten rausgeben GAMING. Nicht an User und nicht an NN Moderatoren oder Administratoren. Nutzt dazu bitte Teamviewer, AnyDesk oder andere Bildschirmübertragungsmöglichkeiten.
TS Support ist nicht verboten, aber auch nicht gerne gesehen. Denkt bitte daran am Ende das Ergebnis hier fest zu halten. Danke.
Ja, wir machen es per Teamviewer. Ist zwar jetzt nicht so meins, aber mach ich zur not auch.
Aus Gründen der Sicherheit hab ich ja auch geschrieben er soll einen Neuen Benutzer erstellen der "Nur" Sudoer Rechte hat.
Als Sudoer kommt man trotzdem nicht auf System relevante Sachen bei Linux
Aber natürlich hast du recht Alice Kingsleigh , man kann sich ja nie sicher genug sein 
Fangen wir mal an:
Es muss natürlich Version 1031 von extDB3 genutzt werden, die hier zu finden ist:
https://bitbucket.org/torndeco/extdb3/downloads/
Damit extDB3 auch funktioniert müssen einige Packete installiert werden.
Um die fehlenden Abhänigkeiten zu sehen nutze: ldd extDB3.so
Dies sieht dann ungefähr so aus:
ldd extDB3.so
linux-gate.so.1 (0xf7f26000)
libtbbmalloc.so.2 => /lib/i386-linux-gnu/libtbbmalloc.so.2 (0xf79a0000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf799a000)
libz.so.1 => /lib32/libz.so.1 (0xf797b000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7875000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7854000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7676000)
/lib/ld-linux.so.2 (0xf7f28000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf766b000)
libatomic.so.1 => /lib/i386-linux-gnu/libatomic.so.1 (0xf7661000)Sollten dort Packete fehlen, findest du diese, in dem du die fehlende Datei hier suchst:
https://www.debian.org/distrib/packages#search_contents
Damit extDB3 auch logs erstellt, muss der auszuführende Nutzer natürlich im Log Verzeichniss Schreibrechte besitzen.
Wenn man Dateien als root hochlädt, entsteht genau dieses Problem. Daher als auszuführender Nutzer Daten hochladen, oder daran denken die Rechte entsprechend umzustellen!
Linux erstellt standardmäßig keine Logs. Um Logs zu erhalten gibt es mehrere Möglichkeiten:
Eine Variante ist es den Output Stream in eine Datei zu lenken: >> logs/$YEAR/$MONTH/$DATE.log
Eine andere ist es die Log Funktion von screen zu nutzen: -L -Logfile logs/$YEAR/$MONTH/$DATE.log
Zwecks den Rechten:
Man setzt nicht das Recht 755 auf alle Dateien. Auf Verzeichnisse ist 755 in Ordnung (wenn man das überhaupt möchte).
Denn jeder Nutzer könnte aktuell den Server starten.
Das Rechte System ist total einfach und gut verständlich:
Es gibt diese "komischen" Zahlen/Buchstaben, die die Rechte verwalten:
Je nachdem wie diese Zahlen/Buchstaben kombiniert werden, dürfen die User etwas machen:
Die 4/r steht also für reine Leserechte und die 6/rw steht für Lesen und Schreiben.
Dies sollte nun klar sein.
Nun gibt es aber nun diese Zahl dreimal.
Ansonsten wir das hier nochmal erklärt:
https://www.guru99.com/file-permissions.html
Nicht zu vergessen.
Du startest den Server mit dem Nutzer root.
Dies sollte man keinesfalls machen!
der File "core" ist an der stelle unlogisch. Den gibt es eig. nur im Altis.Life Ordner.
Und was sehr unschön ist, du nutzt für "@extDB3, @life_server, basic.cfg, server.cfg und core(keine ahnung ob das sinn macht)" Root als ausführendes Element. Das ist bei Linux nicht unbedingt hilfreich, besser wäre du machst alles über den Benutzer "arma" und setzt diesen auf die Sudoers liste
Da der Server als Benutzer "arma" keine dinge vom "Root" ausführen kann
Die Datei core wird vom Server selbst erstellt und immer wieder überschrieben.
Wie oben angesprochen, die Rechte entscheiden, welcher User was ausführen darf.
Es ist nicht erforderlich den Nutzer arma sudo Rechte zu geben. Das sollte man sowieso nur dann machen, wenn man weiß was man tut.
Ich hoffe ich habe alle Unklarheiten die bisher aufgetaucht sind behandelt.
Also bei mir schon denn ich hänge durchgehend im Arma ladescreen und es geht nichts weiter.
x64
extDB2 ist 32-bit only weil seit ~5 Jahren outdated. extDB3 nutzen ist angesagt
extDB2 ist 32-bit only weil seit ~5 Jahren outdated. extDB3 nutzen ist angesagt
Nachdem der Arma 3 Server für Linux sowieso nur in der 32 Bit vorhanden ist, macht das keinen Unterschied.
Aber ja, extDB2 sollte nicht mehr genutzt werden.