Jump to content
LAST CALL on the Unraid Summer Sale! 😎 ⌛ ×

sonic6

Members
  • Posts

    642
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by sonic6

  1. 50 minutes ago, Anym001 said:

    @sonic6 Wie würde denn das Wiederherstellen eines solchen backups funktionieren?

     

    schreib mal folgenden Command ins Terminal:

    lxc-autobackup -h

    @ich777 hat hier an auch an einen simplen restore per lxc-autobackup Funktion gedacht

     

     

    Falls du aber ein manuell machen möchtest, hätte ich noch die Holzhammer-Methode (not-recommended):

    Spoiler

    Den Inhalt der .tar einfach in den Ordner des Container innerhalb deine LXC shares entpacken.
    Dann würde der Container genau dem Ursprung entsprechen.

     

    Du kannst aber auch einen neuen Ordner erstellen und dann die config in der .tar anpassen um einen anderen Container aus dem Backup zu erstellen.

     

    Schau dir einfach mal den Inhalt deines Backup an und dem in deinem LXC share, dann wirst du recht schnell verstehen, wie simple die Wiederherstellung ist.

     

    • Like 2
  2. the new update causes email notifications:

    image.thumb.png.df20ee6fe46637e1de112257e85f4cda.png

     

    Nov 25 11:39:11 Unraid-1 emhttpd: spinning down /dev/sdg
    Nov 25 11:45:01 Unraid-1 crond[1468]: exit status 127 from user root /usr/local/emhttp/plugins/DriveStandbyMonitor/monitor.sh
    Nov 25 11:45:01 Unraid-1 sSMTP[30712]: Creating SSL connection to host
    Nov 25 11:45:01 Unraid-1 sSMTP[30712]: SSL connection using TLS_AES_256_GCM_SHA384
    Nov 25 11:45:03 Unraid-1 sSMTP[30712]: Sent mail for root@*****.de (221 2.0.0 Bye) uid=0 username=root outbytes=549

     

    diagnostic is attaced

    unraid-1-syslog-20231125-1052.zip

  3. 1 hour ago, GhostLeader said:

    Du hast ins Backend folgendes geschrieben: Note: Also add the DNS line if you errors in the container logs that it can't get the manifests due to a 401 unauthorized.

     

    Diese Hinweis habe ich aus der Github Readme des Entwicklers übernommen.

     

    1 hour ago, GhostLeader said:

    Das muss dann bestimmt ebenfalls in die Extra Parameter oder? Wie würde der Eintrag dann aussehen den man dort einträgt?

    Genau, so in etwa:

    image.thumb.png.269a761b0cf59e3a14dde29559cdd1d8.png

    Quelle:

    https://github.com/devedse/DeveLanCacheUI_Backend#develancacheui_backend

  4. 5 minutes ago, GhostLeader said:

    versteh ich das falsch?

    ja

     

    6 minutes ago, GhostLeader said:

    Also bezieht sich deine Beschreibung doch auf den standard Brdige modus

    nein, sondern wie in der Template Info auf die Custom User Bride. Hierzu bitte einmal hier einlesen: https://docs.docker.com/network/drivers/

     

    8 minutes ago, GhostLeader said:

    wo dann auch 7301 korrekt wäre

    Die Costum User Bride, bzw eine "user defined brdige" (oder custom user network) verhält sich ähnlich wie die "standart Bridge".

    Der für DIESEN (und auch einige andere) Container entscheidende unterschied ist die DNS Auflösung der Container Hostname ( mehr dazu hier: https://docs.docker.com/network/drivers/bridge/#differences-between-user-defined-bridges-and-the-default-bridge ).

     

    Ich weiß, dass man im Frontend Container die IP des Backend angeben kann. Bei mir hat das aber nicht richtig funktioniert, da das Ziel per Hostname Hardcoded (war).

     

    Daher habe ich das Template so angelegt (und auch den Hinweis hinterlegt), dass ein Custom User Network genutzt werden sollte.

  5. 4 minutes ago, GhostLeader said:

    In der Beschreibung steht aber: http://YOUR-UNRAID-IP:7301

    Genau, weil sich die Beschreibung auf den Einsatz in einem Custom User Network bezieht. Dort wäre dann der Host Port zu nehmen. Da du das ganze aber als Custom User Bride br0 nutzt, gibt es den "Host Port" nicht. Daher wäre dann Port 80 korrekt.

    Du vermischt halt die Beschreibung und dass du dich nicht an die "empfohlene Vorgabe" gehalten hast ;)

     

    7 minutes ago, GhostLeader said:

    Vielleicht kannst du noch zu diesem Warming was sagen: Tried to obtain manifest for: 2347771 but status code was: Unauthorized

    Hierzu kann ich nichts sagen, da der Container nicht von mir ist. Ich habe nur das Template für die Nutzung in Unraid zum Bezug über die CA bereitgestellt.

  6. Moin @GhostLeader, ich wüsste persönlich nicht, was ich groß in eine Anleitung schreiben sollte.

    Es gibt, abgesehen vom Port, noch zwei Dinge die man am Backend anpassen muss:

    -Netzwerk auf eine Custom User Bride. (Ob br0/eth0 funktioniert, hängt ganz von deinem DNS im LAN ab.)

    -Pfad zum LANCache Log

     

    Ohne einen Log oder was bei dir schiefläuft, kann ich dir nicht sehr gut weiterhelfen.

    Mein Tipp wäre in erster Linie auf eine Custom User Bride (custom user network) umzustellen.

  7. 2 hours ago, Alku1 said:

    Aber wirklich irre, dass man die info wirklich nirgends findet!?

    doch, man sieht ja wo die Ordner gemounted sind im Template. habe deswegen extra den screenshot eingefügt in meiner letzten antwort.

     

    freut mich aber, dass es nun klappt.

  8. 3 hours ago, Alku1 said:

    Das Verzeichnis "custom_zha_quirks" habe ich in einem neuen Unterverzeichnis "config" im HA docker erstellt.

    das Verzeichnis "config" besteht schon:

    image.thumb.png.832c405761e1dabd19d44d2b114971b6.png

    Sprich dein Verzeichniss /homeassistant/ in /mnt/user/appdata  entspricht im Container dem Verzeichnis /config/ .

     

    Du musst nur folgendes Verzeichnis erstellen:

    /mnt/user/appdata/homeassistant/custom_zha_quirks/

    und schon gehts.

     

    • Like 1
  9. 2 hours ago, xokia said:

    Latest update to intel-GPU Top seems have killed HW transcode. GPU is doing something but most of the processing is now done by CPU.

    How do I go back to the prior version?

    it wasn't intel-gpu-top, it was the latest Plex update.
    if you are using the LSIO container, try v1.32.5.7349-8f4248874 which worked fine.

     

    1 hour ago, ich777 said:

    This is a well known issue, you should report that on the Plex forums, this only affects the Plex web client on all platforms, it‘s also not related if you are using Intel, Nvidia, AMD for transcodig.

     

    This is a Plex issue.

    this problem isn't the web client, it is the latest update.
    if you are using any other clients or platforms and using the HDR tonemapping, it won't use hardware transcoding:
     

    Quote

     

    Folks,

    Sure you've all heard of the changes we had.

    We lost a lot of good people.

    The fundamental problem was there wasn't ample time to do a coordinated hand-off of work. Unfortunately stuff got lost in that transition (institutional knowledge)

    We know of the regressions. We've got a few of the transcoder regressions fixed already.I'm working on isolating another.

    Here's what I know

    HEVC HDR -> SDR tonemapping does fail for folks.There isn't a pattern yet. (What I'm trying to identify)

    Turn HDR -> SDR tonemapping OFF and it HW transcoding works reliably again.

    This looks like a OpenCL problem with Intel CPUs but I've not completed investigating.

    If folks want to come to the forum and help me with more info, I would greatly welcome it.There are not enough hours in the day for me to support the forum, development, and Reddit.

    My priorities are Forum & Development for now.Hope you all understand.

     

    Source:

     

    • Like 1
  10. 15 minutes ago, wayner said:

    Sorry, but it isn't clear what the simplest solution is from the changelog.

    you are right, the first try is the change to ipvlan, but of your hardware need a seperated MAC-Address per device, or had other conflicts with ipvlan, then use "eth0".

    (i am using a fritzbox, which needs seperated MAC-Addresses per device).

     

     

    10 hours ago, wayner said:

    but I have a Ubiquiti router

    with your hardware i would strait go to the "eth0" solution.

     

    18 minutes ago, wayner said:

    But are you saying to stay with macvlan and change from br0 to eth0?

    yes, i would do that. read carefully the changelog.
    in short: stop docker, disable array autostart, update unraid, reboot unraid, disable bridging in network settings, activate "host access" in docker settings, start docker, check if all br0 container are started.

    if not all container started, check if they changed from br0 to eth0. if some container disapeared go to "add container" on docker page, choose your template. change from br0 to bridge, start the container, edit the container again and change it to eth0.

     

    after all runs activate the array autostart again.

     

    now you should check you router etc, because the MAC-Addresses of your container could be change, also there is a second MAC-Address with the same IP address like your unraid host. this is normal.

  11. On 7/18/2023 at 3:43 PM, sonic6 said:

    @JorgeB @bonienl

    can that "solution" marked as "deprecated"?

    more and more users sped time changing they're system, with the hope of fixing the traces. but it doesn't work, this only confuses.

     

    @JorgeB @bonienl

    maybe NOW is the time, to mark this as "deprected" as a fix for MACVLAN?
    Maybe unipin it, and edition the first Post with a hint to update to 6.12.4 instead of using two NICs?

     

    There a still users, who are confused by this """"solution"""

  12. Gibt im Container Terminal danach testweise mal "ip address" ein, dann sollte dir die IP Adressen des Containers aufgelistet werden.

     

    Kleiner Tipp am Rande: deaktiviere den DHCPv6 und lass die Adresszuweisung per SLAAC stattfinden.

  13. 17 minutes ago, Mainfrezzer said:

    Für zuhause ist das Jacke wie Hose. Da könnt auch nen pinkes Schweinchen drauf sitzen und es macht kein Unterschied.

    Du kannst dir auch n Loch ins Knie bohren und Maggie reinkippen, würde das aber trotzdem keinem dritten hier empfehlen...

     

     

    18 minutes ago, Mainfrezzer said:

    Eben dass man LLA-ULA-GUA nicht wirklich beeinflussen kann

    Du kannst ULA sehr wohl beeinflussen. Das prefix wird per SLAAC oder DHCPv6 vom Router vorgeben und die MAC kommt von der Hardware.

    Alles andere ist eine Frage des routings und was man konfiguriert.

     

    Mein Pihole läuft als LXC Container problemlos per ipv4/6 im LAN. Sogar innerhalb eines Docker User Network läuft IPv6. Selbst anfragen die über den CF-Tunnel kommen, funktionieren.

  14. 8 hours ago, Mainfrezzer said:

    Ohne statische Präfixzuweisung bleibt intern nur die LLA

    LLA ist aber nicht für Nutzdaten bestimmt und nicht für das Routen in andere Netze bestimmt, dafür gibt es ULA.

     

    Das statische Präfix bekommst du über die ULA, das wechselnde Präfix der GUA erledigt man über ein DDNS Script. Man kann einem Gerät ja auch ohne weiteres mehere IPv4/IPv6 Adressen mitgeben. Wo ist also das Problem?

    Da es hier um (wie ich Anfangs überlesen hatte) eine "lokale" Verfügbarkeit des Container geht, einfach MACVLAN mit eth0 nutzen und dem Container eine ULA zuteilen. Ggf. wie @KluthR schon schrieb eine feste MAC vergeben (was bisher bei mir noch nicht nötig war).

    Die Krux ist hier lediglich, dass die automatische Routing Tabelle in Unraid noch wild zwischen ULA und GUA wechselt.

    Daher kann ich IPv6 mit Docker Containern bisher nur per eth0 (früher br0) stabil realisieren.

  15. Ich möchte dein Arbeit in keiner weise schmälern, jedoch ist es wichtig hier für Klarheit im MACVLAN Chaos und den damit verbundenen Vermutungen zu schaffen.

     

    12 hours ago, Rockikone said:

    Die Kernel Fehlermeldungen kamen bei mir auch noch bei aktivierter Netzwerkbrücke unter 6.12.4.

    Das ist Richtig, weil man MACVLAN nicht und nie und niemals zusammen mit einer Bridge nutzen darf. (Warum das in der Vergangenheit gemacht wurde, lassen wir mal dahin gestellt. Auch warum es immer noch möglich ist, finde ich fragwürdig.) Irgendwo im Englischen Bereich gab es hierzu Informationen von den Dev's (Unraid und Kernel), dass man MACVLAN nicht mit einer Bridge betreiben sollte.

    Das war auch der Grund, warum vor Monaten schon IPVLAN als Default Driver für Docker eingeführt wurde.

    Die Lösung die mit 6.12.4 eingeführt wurde, dass man eth0 mit MACVLAN nutzen kann, war lediglich für user gedacht, die aufgrund ihrer Hardware auf MACVLAN angewiesen waren. (Zb die Fritzbox, die mehrere IP Adresse von einer MAC nicht mag.)

    Für alle anderen gilt im ersten Schritt: Auf IPVLAN umstellen.

     

    12 hours ago, Rockikone said:

    Es müssen ja auch mehrere Sachen eingestellt werden (Changelog nicht ganz ersichtlich). Darum meine Anleitung.

    Das eine Bridge nicht mehr mit MACVLAN zu betreiben ist, steht im Changelog recht detailliert, auch was hierfür zutun ist um unter MACVLAN auf eth0 umzustellen.

  16. 4 hours ago, Rockikone said:

    die Netzwerkbrückung deaktiviert.

     

    4 hours ago, Rockikone said:

    seit 2 Tagen stabil und ich habe keinerlei Kernel Fehlermeldungen aufgrund macvlan.

     

    fall dein Server auf 6.12.4 läuft, könnte es eher an 6.4.12 liegen, dass es keine probleme mehr mit macvlan gibt.

    Für alle anderen, die aufgrund von den MACVLAN Traces hier gelandet sind: Ließt den 6.12.4 Changelog, geht die manuellen Schritte durch und updated, danach sind die MACVLAN Probleme Geschichte.

    Für alle anderen Fälle, danke natürlich für deinen Aufwand.

  17. hi, today i tried mounting an HDD via temrinal with:

    /usr/local/sbin/rc.unassigned mount /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K0VZ4TVK
    sleep 30s

    but the drive wan't moutable:

    Sep  4 06:43:13 Unraid-1 emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/startScript.sh /tmp/user.scripts/tmpScripts/Backup-to-UD/script 
    Sep  4 06:43:14 Unraid-1 unassigned.devices: Mounting partition 'sdd1' at mountpoint '/mnt/disks/WD-WCC7K0VZ4TVK'...
    Sep  4 06:43:14 Unraid-1 unassigned.devices: Mount cmd: /sbin/mount -t 'xfs' -o rw,noatime,nodiratime '/dev/sdd1' '/mnt/disks/WD-WCC7K0VZ4TVK'
    Sep  4 06:43:21 Unraid-1 kernel: XFS (sdd1): Mounting V5 Filesystem
    Sep  4 06:43:21 Unraid-1 kernel: XFS (sdd1): log mount failed
    Sep  4 06:43:21 Unraid-1 emhttpd: read SMART /dev/sdd

     

    late i tried mounting with the GUI Button and that worked well. i unmounted the drive and tried again the terminal and that also worked now.

     

    i report this just for the case. diag is attached.

    unraid-1-diagnostics-20230904-0719.zip

  18. On 9/1/2023 at 4:22 PM, mgutt said:

    This confuses me. Why was "from" empty?

    Hm, i did test it again and it works well...

    I am using an unmounted UD as destination and mount es with:

    /usr/local/sbin/rc.unassigned mount /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7K0VZ4TVK
    sleep 30s

    Maybe be the drive wasn't mouinted correctly? 

     

    Can you add a "check" if the destination ist available?

  19. 19 hours ago, KluthR said:

    Ich nutze nach wie vor die „—mac-address=„ option um eine feste v6 zu setzen.

    das Prefix wird sich dennoch weiterhin ändern.

     

    19 hours ago, Joly0 said:

    habe auch schon bemerkt, dass sich der prefix immer wieder ändert

    sollte kein problem sein, das Prefix verhält sich wie deine IPv4... sie ändert sich. Also gehst du wie bei IPv4 vor und erstellst eine DDNS auf die IPv6 des Container (nicht vom Host).

×
×
  • Create New...