vakilando

Hallo @Sickhead78, bei läuft MailCow seit gestern. Ich habe zwar momentan einige Problemchen die Daten meiner alte Mailcow VM (Debian 9) zu migrieren, aber die Installation unter Unraid hat nach einigen Anläufen gut geklappt. Beschreibung ist hier:

Important note: Your data will persist in multiple Docker volumes, that are not deleted when you recreate or delete containers. Run docker volume ls to see a list of all volumes. You can safely run docker compose down without removing persistent data. (See https://docs.mailcow.email/getstarted/install/#start-mailcow) But, very importasnt note: I have a user script that removes "dangeling docker images" using these commands: ### delete immages docker rmi $(docker images --filter "dangling=true" -q --no-trunc) #delete volumes docker volume rm $(docker volume ls -qf dangling=true) NEVER start this script while Mailcow is NOT running, because it WILL remove those MailCow Docker volumes where the persistand data is stored.....

@Marshalleq @Gremmi a bit late, but yes got it working without am VM (yesterday). I still have my VM productive, but it's an old debian 9 so I have to replace it.... This is what has to be done: mkdir /mnt/cache/appdata/mailcowdockerized cd /mnt/cache/appdata/mailcowdockerized git clone https://github.com/mailcow/mailcow-dockerized ./generate_config.sh This generates two files whose content is needed for the Unraid Plugin Docker Compose.Manager: - docker-compose.yml - mailcow.conf Then edit the file "mailcow.conf" to your needs: I changed the HTTP and HTTPS Ports. Then edit the file "docker-compose.yaml" for the volume paths to match your appdata path: In my case I changed all volume paths by replacing all strings that began with "- ./data/" with "- /mnt/cache/appdata/mailcowdockerized/data/" Important: Do this BEFORE starting the Stack for the first time! Then add a new Stack "mailcow" with the Plugin Compose.Manager for Docker and edit it: Select Stack File to Edit: COMPOSE FILE Copy the content of the modified file "docker-compose.yml" and paste it here Select Stack File to Edit: ENV FILE Copy the the content of the modified file "mailcow.conf" and paste it here Then pushed the button "Compose up" Et voilà, MailCow whith SOGo is up.

Die erste Frage wäre, wie hoch sind denn die Temperaturen sonst so? Meine Arry HDDs haben eine Temperatur von 24 Grad wenn ich sie aus dem Idle aufwecke. Wie hoch sie ist wenn sie länger in Betrieb sind muss ich noch gucken... Wenn deine Grundtemperatur schon hoch ist kann das schon sein, dass dein Array beim Parity Check zu warm wird.

Ich kann mich nur auf die Seite von @ich777 stellen und ihm zustimmen.... Ich habe von Anfang an (seit über 5 Jahren) einen Btrfs Cache Pool (RAID1). Tatsächlich hatte ich einmal defekte SSDs (der Pool bestand damals aus 2 x SanDisk SSD PLUS 480GB), diese sind beide kurz hintereinander gestorben.... Siehe auch Allerdings habe ich danach mit zwei Crucial MX500 1 TB SSDs erneut einen Btrfs Cache aufgebaut mit zwei "Modifikationen": - Docker directory anstelle von Docker Image - bei allen Docker Containern unter "Extra Parameter" folgendes hinzugefügt: "--no-healthcheck" Dieser Btrfs RAID1 Cache Pool läuft bis heute anstandslos. @Archonw, dass man vor allem kein BTRFS im Pool benutzen sollte, wenn man bei Docker von "Image" auf "Directory" umgestellt hat ist auch das erste was ich höre. Die ZFS Option finde ich durchaus interessant, habe aber derzeit keine Notwendigkeit umzustellen und warte daher lieber noch ab bis die ZFS Integration einfacher/vollständiger/ausgereifter ist.

Ja, für alle Toner musste ich gerade 206 € berappen (original Canon). Die vermeintlich günstigeren Nachahmer/refill sind teuer, da sie irgendwann anfangen unschöne Streifen zu produzieren und vorzeitig ausgemustert werden mussten (bisher nur der schwarze). Ob der Scansnap OCR direkt beherrscht würde mich interessieren, muss ich noch mal nachschauen. Auf jeden Fall ist er bedeutend schneller und hat sicherlich einen besseren Einzug (in seltenen Fällen zieht der Canon auch mal 2 Blatt ein und motzt dann piepend nach Unterstützung).

Es sind halt schon stark unterschiedliche Geräte. Der Canon kann alles und der Scansnap kann nur scannen, ist in dieser Disziplin aber um Meilen schneller und besser. 30 Seiten/Min ist schon ne Ansage. Macht der OCR intern oder über die Software, weißt du das? Also hängt es vor allem von Einsatzhäufigkeit und Menge der zu scannenden Dokumenten ab was hier die bessere Wahl ist.

Ich habe den Canon i-Sensys MF635cx und bin rundum zufrieden. Er hat LAN und WLAN. Er legt die gescannten Dokumente (mit OCR) in einen Ordner (Samba Share). Ich verschiebe diese nach Umbenennung ggf. in einen Ordner aus dem Docspell sie dann abholt. Ich habe auch wert auf einen Drucker gelegt, der von Linux gut unterstützt wird bzw. Arbeitsschritte (scan-->OCR-->Share) übernimmt.

I sadly must agree @NewDisplayName.... I had Xeoma up and running for quite a long time. It worked very well and was rock solid too, but the container is no longer maintained by @coppit I have more cameras than my licence admits costs are too high to upgrade I still have the xeoma container installed because I like the drag an drop configuration very much dispite of a quite ugly interface but I'll move on to frigate.

Yes this is a serious problem that should be fixed! Last year one of my 2 SSD from my BTRFS cache pool died and I did not get any notifications. By luck I saw the warnings and errors in the syslog and replaced the disk. I found a script written by mutt that "that" looks for errors in the syslog and then generates an notification. It works well but I don't know if it's compatible to UnRAID 6.12 (I'm still on 6.11). Something like this should (must?) be part of UnRAID....

Hast du unter den Docker Einstellungen Host-Zugang zu benutzerdefinierten Netzwerken aktiviert? Wenn ja, schau mal in den Einstellungen unter Netzwerk ob in der Routing Tabelle die shim Einträge noch vorhanden sind. Wenn nicht Docker beenden, Host-Zugang zu benutzerdefinierten Netzwerken deaktivieren, wieder aktivieren und Dockerdienst neu starten.

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?