vakilando

ja, das ist natürlich richtig! Der Container Ersteller muss das "Feature" in seinen Container eingebaut haben. Am besten du schaust auf der Seite des Erstellers (hub.docker.com, github, ...), oder im Unraid Support Thread ob eine entsprechende Option genannt wird / dokumentiert ist.

Das entscheidet der Ersteller/Entwickler des Containers. Du kannst es aber auch selbst beeinflussen indem du entsprechende Container Variablen erstellt. Ich glaube USR_ID=99 und GRP_ID=100 wenn du den Container mit unraid Standard User laufen lassen willst und jeweils "0" wenn der Container als root laufen soll. Ganz sicher bin ich nicht, bin unterwegs und müsste daheim nachschauen.

Bei mit stand bei AdGuard nach der Installation des Dockers unter "WebUI" => "http://[IP]:[PORT:6052]/" Funktionieren tat aber nur Port 80......Also habe ich es auf "http://[IP]:[PORT:80]/" umgestellt. Als Portvariable ist außerdem folgendes voreingestellt: WebUI: 3000 (Container Port: 3000 Port for the Web UI) ....funzt aber dennoch nur mit Port 80. Die Einstellung habe ich auf 3000 belassen.....

Du musst unter "Einstellungen > Globale Freigabeeinstellungen" den ersten Eintrag "Freigaben aktivieren:" von "Auto" auf "Ja" umstellen. ABER: Hast du das gelesen In deinem Link Disk Share? IMPORTANT If you have both Disk Shares and User Shares enabled then there is an important restriction that you must observe if you want to avoid potential data loss. What you must NEVER do is copy between a User Share and a Disk Share in the same copy operation where the folder name on the Disk Share corresponds to the User Share name. This is because at the base system level Linux does not understand User Shares and therefore that a file on a Disk Share and a User Share can be different views of the same file. If you mix the share types in the same copy command you can end up trying to copy the file to itself which results in the file being truncated to zero length and its content thus being lost. There is no problem if the copy is between shares of the same type, or copying to/from a disk mounted as an Unassigned Device.. Und warum willst du das überhaupt machen? Ich würde das nur mit einer Platte im Array machen, die von allen User shares ausgenommen ist, da kann es aus Sinn ergeben die ganze Platte freizugeben.

not a bad idea indeed +1

I got it working! Solution was quite simple.... (no login) => remove characters from password like: §, $, %, & (black pictures) => I don't know why, but the account for the web server module had a wrong password set

In my case: Avoid special characters in the passwords like: "§ $ % &" !!!

You are using the administrotor account, right? I have a similar problem with the administrotor account, I don't get a 404 error but a "wrong login/password" message. I can only login with my second non administrative account, but the I have black pictures. Try creating a second non administrative account with the Xeoma client (Linux/Win) and with that try to login to the webinterface.

@Alex24 version 22.12.5 is working for me - partially... The docker starts up, I can connect to the xeoma server with the linux client software an I see the cameras with pictures. The xeoma web server also starts successfully but I can't login with my admin account. It says wrong password although it isn't wrong! I can login with my second account, but the camera prictures are just black....

@Maniek2as2 can you show us your logs and your configuration? If you use this container, did you follow the instructions from here https://github.com/coppit/docker-xeoma-server: "When run for the first time, a file named xeoma.conf will be created in the config dir, and the container will exit. Edit this file, setting the client password."

Hallo @Alex24, ich meinte welchen Docker Container du von hub.docker.com installiert hast. Ich verwende https://hub.docker.com/r/coppit/xeoma/ und hatte die von mir hier im beschriebenen Probleme: Hello @Alex24, I ment wich container you are using from hub.docker.com. I installed https://hub.docker.com/r/coppit/xeoma/ and had following problems: Ich werde die Tage mal Version 22.12.15 testen.

irgendwie verstehe ich deine Frage nicht.... Du hast eine MZHOU PCIe SATA X4 Karte: Daran schließt du über ganz normale SATA Kabel deine Festplatten an. Du schreibst aber, dass du dir ein SAS Kabel mit 36 Pin-Stecker gekauft hast, dieses an deinen Server angeschlossen hast "und die einzelnen SATA Anschlüsse an die SATA Karte geschlossen" hast?? Wie geht das denn? (ich muss das falsch verstanden haben...!) Gleichzeitig schreibst du "Mit alten SAS Controller in IT Modus funktioniert das einwandfrei". Also musst du doch bereits ein solches Kabel gehabt haben? Schreib doch bitte noch mal genauer was du gemacht hast - oder jemand anderes versteht was du geschrieben hast....

Zudem dachte ich es wird nicht mehr produziert, aber im Angebot steht: "Auslaufartikel (Produktion durch Hersteller eingestellt)‎: Nein". Hmmm.... Ich suche eigentlich auch ein (stromsparendes) Ersatzboard....

@Alex24 welchen Docker Container verwendest du, hattest du mit Version 22.8.16 auch die Probleme wie hier im Thread beschrieben? Which docker container are you using? Did you have similar problems with version 22.8.16 as discribed in this thread?

Was somebody successfull installing the latest version 22.12.5 of Xeoma?? I'm still on version 22.3.16....