sonic6

Members
  • Posts

    601
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by sonic6

  1. On 4/29/2023 at 6:26 PM, KluthR said:

    It is! Noted.

    any news about this? i want to backup my plex DBs, but not all the picture cach, as an example. my appdate backup growes up from 8gb to 40gb when i switch over from Unraid 6.11.5 to 6.12.1

  2. 19 minutes ago, Zeze21 said:

    Ich möchte wirklich GERNE den bug melden,[...]
    An deinen Thread werde ich mich gleich nach der Arbeit dranhängen!

    Das Anhängen sollte passen, im Idealfall die Diagnostic, mit Anhängen.

     

     

    20 minutes ago, Zeze21 said:

    Alle von mir geschilderten Probleme traten erst mit dem Update auf 6.12 auf ergo müsste doch hier der Fehler zu suchen sein?

    Ähnlich berichten @alturismo und ich auch. Unsere Probleme kamen erst mit dem Wechsel auf 6.12., aber andere User hatte schon unter 6.11.x und 6.10.x Probleme.

     

    Fairerweise muss man auch sagen, dass das Problem kaum greifbar ist für das Unraid-Team ist, da es so weit gestreut ist.

    • Like 1
  3. 10 hours ago, cz13 said:

    FRITZ!Boxen und 6.12.x

    Das hat nichts mit 6.12.x zutun, viel mehr mit macvlan und die aggressive Verbreitung durch das Unraid Team, dass IPVLAN das Allheil-Mittel ist.

    Aber genau hier beißt sich die Katze in den Schwanz, primär wir DACH User (oder sogar nur wie DE User) haben in Summe viele AVM Fritzboxen im Einsatz, die IPVLAN Technisch einfach nicht unterstützen. (Weitere Infos bitte direkt bei AVM erfragen. Vielleicht sogar einfach mal offensiv um untestützung bitten, um einen Bedarf daran anzumelden.)

     

    @Zeze21 und alle weiteren Betroffenen, ich BITTE inständig darum einen Bug zu reporten, oder sich mindestens an meinen Thread ran zu hängen.

    Es gibt immer mehr Beiträge dazu im Forum und Reddit, aber niemand reported den Bug, somit hat das ganze Thema keine-bis-kaum Relevanz für das Unraid Team.

    • Like 2
  4. 1 hour ago, BurntOC said:

    The server hangs finally drove me to abandon macvlan for now and I flipped the switch back to ipvlan again.  I've rebooted a couple of times since for various reasons, then in reviewing my FCP scan this morning it is still reporting DOZENS of macvlan call trace warnings - and I'm not running macvlan.  Meanwhile my very similar Unraid server with the same model quad nic and pretty similar network setup (on a 10th gen Intel vs the 11th gen on this one) hums along on macvlan very nicely.  Frustration peaking.

    You should open a Bug Report with your Diagnostic File 

  5. 2 hours ago, insomnia417 said:

    按照你的方法,我最近升级了6.12 rc5 rc6 , macvlan没有导致报错死机,但是,我用br1创建的br网络,与macvlan不能互相访问,已经开了主机自定义访问

    i think hostaccess isn't possible with this "solution",... so in my eyes this isn't a real "solution" for the whole "macvlan issue". maybe it also should't be named as that.

  6. 25 minutes ago, JorgeB said:

    This is a device error, and not the first one.

    Don't get me wrong, but i don't really get what you mean.

     

    This isn't the first one of this errors which was reported?

    This isn't the first error in my syslogs? (I know, there were 6 one befor, the posted one was just an example)

    Do i have to be worried about, and/or is the device broken, or misconfigured?

  7. With a random look in my Syslog i found the following from time to time when i got heavy load on my nvme cache drive:

     

    May 15 00:52:59 Unraid-1 kernel: nvme0n1: I/O Cmd(0x2) @ LBA 551285192, 512 blocks, I/O Error (sct 0x2 / sc 0x81) MORE 
    May 15 00:52:59 Unraid-1 kernel: critical medium error, dev nvme0n1, sector 551285192 op 0x0:(READ) flags 0x84700 phys_seg 64 prio class 0
    May 15 00:52:59 Unraid-1 kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 914 off 81920 (dev /dev/nvme0n1p1 sector 551282632)

    nvme: https://jp.transcend-info.com/products/images/modelpic/991/Transcend-PCIeSSD220S.pdf

    Diagnostic is attaced.

     

    i use two of this in a btrfs-raid1 as a cache drive for appdata, docker and VMs.

    i got the same message when i did a scrub.

    both nvme's are connected to the onboard M.2 slot. (more details in my signature)

     

    should i be worried about that? the drive is just 2 month old with a runtime of 977 hours. should i do a RMA?

    i didn't saw the same for nvme1n1 (second drive from btrfs-raid1).

     

    thank you, for helping me :)

    unraid-1-diagnostics-20230516-1345.zip

  8. srsly? for short and stupid (sorry for that). Unraid Connect is a simple Cloud Service and isn't made for selfhost. I don't understand people like you... there is a simple service for beginners, not more not less.

     

    If you are a beginner, use it.

    If you are a "skilled user" search for another selfhost solution.

    • Confused 1
  9. 14 minutes ago, SuberSeb said:

    If you want to use Unraid Connect, you don't have options here and you have to loose some control over your services and data.

    You have.

    Set up your own ReverseProxy and do your own Service.

    Google will also not publish a selfhost "Google Drive". But you can use other similar Serverices selfhosted. It is the same with Unraid Connect. It isn't for selfhost, but you will find a similar solution for you.

    17 minutes ago, SuberSeb said:

    I'm not sure what you mean by this, but you don't get my point.

    I got what you meant, but Unraid Connect isn't what you expected.

    I meant, when you are someone who are skilled enough hosting a VPS, then you can search and find your own solution and don't need Unraid Connect.

  10. 6 hours ago, mgutt said:

    Kann man das irgendwie auf 100% Zuverlässigkeit bekommen? zB in dem der das Kommando 2x absetzt oder prüft, ob der finale Status wirklich erreicht wurde und falls nicht, dann noch mal das Kommando sendet?!

    Das sollte doch bestimmt über ne Schleife in der Automation klappen. Vielleicht in Verbindung mit ner Helfer Entität die vorher den Status der Steckdose übernimmt?

    Keine Ahnung ob das zu komplex gedacht ist?

  11. i think you said the whole point:

     

    5 hours ago, SuberSeb said:

    Also many of us have a lot of skills and can easily deploy such kind of service on VPS

     

    if you are someone of this, you don't need unraid connect and host your own services, there are many ways to do this.

    looks like unraid connect is for people who are looking for quick overview or don't have the skill to host services like this.

     

    That is one of the greate thinks with OS's like Unraid: You can do it your own way.

    • Upvote 1
  12. 3 minutes ago, mgutt said:

    Also wenn du was über den Browser hochlädst, siehst du in dem Ordner 10MB Chunks und sonst 1GB?

    Genau, den Output vom Browserupload habe ich mir gespart. Der gepostete Output war von der Nextcloud Windows App.

     

    *edit*

     

    Es könnte hieran liegen:

    Quote

    [General] section

     

    chunkSize 10000000 

    (10 MB)Specifies the chunk size of uploaded files in bytes. The client will dynamically adjust this size within the maximum and minimum bounds (see below).

     

    maxChunkSize 100000000 

    (100 MB)Specifies the maximum chunk size of uploaded files in bytes.

     

    minChunkSize 1000000 

    (1 MB)Specifies the minimum chunk size of uploaded files in bytes.

    Quelle: https://docs.nextcloud.com/desktop/3.2/advancedusage.html?highlight=chunk

     

    Habe gerade aber keine Möglichkeit das zu prüfen.

  13. On 4/13/2023 at 6:02 PM, mgutt said:

    Mit dem Befehl während dem Upload:

     

    find /mnt/user/appdata/nextcloud/data/*/uploads -type f -exec ls -lah {} \;

     

    Ich kann jedem nur empfehlen auf zumindest 64 MiB zu erhöhen. Deutlich weniger Chunking und damit mehr Performance.

     

    Also falls es jemand mit dem LSIO Container Testen will:

     

    find /mnt/user/nextcloud/*/uploads -type f -exec ls -lah {} \;

     

    Mir ist aufgefallen, dass das Chunking hier bei 10MB aus dem Webbrowser lag, jedoch über die Windows Anwendung folgendes zeigt:

    root@Unraid-1:~# find /mnt/user/nextcloud/*/uploads -type f -exec ls -lah {} \;
    -rw-r--r-- 1 nobody users 9.6M Apr 16 09:58 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000000
    -rw-r--r-- 1 nobody users 570M Apr 16 09:58 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000001
    -rw-r--r-- 1 nobody users 953M Apr 16 09:59 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000002
    -rw-r--r-- 1 nobody users 954M Apr 16 10:00 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000003
    -rw-r--r-- 1 nobody users 954M Apr 16 10:00 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000004
    -rw-r--r-- 1 nobody users 954M Apr 16 10:01 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000005
    -rw-r--r-- 1 nobody users 954M Apr 16 10:02 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000006

    Hier scheint die Größe der Chunks bei ca 1GB zu liegen.

    Wenn man das noch anpassen könnte und sich das auch aufs WebDAV auswirken würde, wäre der CF-Tunnel wieder eine Option für die NC.

  14. On 4/12/2023 at 9:17 PM, mgutt said:

    Das erklärt auch, warum so viele Probleme haben, wenn ihre Nextcloud über den Cloudflare Proxy betrieben wird (der trennt meine ich bei 128MB).

    sollten ca 200MB sein

     

    19 hours ago, mgutt said:

     

    21 hours ago, i-B4se said:

    Wo kann ich das mit dem Chunking sehen?

    Mit dem Befehl während dem Upload:

     

    find /mnt/user/appdata/nextcloud/data/*/uploads -type f -exec ls -lah {} \;

     

    Ich kann jedem nur empfehlen auf zumindest 64 MiB zu erhöhen. Deutlich weniger Chunking und damit mehr Performance.

    ich hatte, abgesehen vom CF Tunnel auch noch nie Probleme damit. Kann es vielleicht sein, dass das Chunking beim LSIO Container im Web default aus ist?

  15. 14 hours ago, mgutt said:

    EDIT: OK etwas gefunden. Nur verstehe ich nicht. Was macht denn das Kommando? Fügt das eine neue Einstellung in der config.php hinzu oder wo schreibt der die Einstellung hin?!

    https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/big_file_upload_configuration.html#adjust-chunk-size-on-nextcloud-side

    sudo -u www-data php occ config:app:set files max_chunk_size --value 20971520

    Kann es sein, dass sich das nur auf die App/Anwendung bezieht?

    Die Chunks sollen ja normalerweise "nur" 10MB groß sein. Zusammen mit dem CF-Tunnel gibt es mit NC über den Browser aber immer Probleme, da der CF-Tunnel nur 200MB Pakete zulässt.

    Die NC Apps über Android/Windows machten hier nie Probleme, Up-/Download hingegen über den Browser brachen nach 200MB aber immer ab.

  16. On 1/16/2023 at 12:47 AM, mgutt said:

    Problem: Alle meine User haben ein unendliches Kontingent. Vom Gefühl her würde ich sagen, dass man lieber einen festen Wert eintragen sollte, damit der Papierkorb nicht immer weiter wächst.

     

    Zusätzlich dachte ich daran, das hier zu machen:

    'trashbin_retention_obligation' => 'auto,30',

    https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/trashbin_configuration.html

     

    Das sollte denke ich bedeuten: Lösche, wenn der Papierkorb mehr als 50% des Kontingents belegt und grundsätzlich alles was länger als 30 Tage im Papierkorb ist.

     

     

    Bin vor ein paar Jahren auf genau die gleiche "Problematik" gestoßen.

    Bin das Problem letztendlich genauso angegangen wie du. Ich habe ein Default Contingent von 20GB gewählt.

    300GB ist für mein System zu viel, da mein Cache nur 500GB sind und ich als Hauptnutzer bisher "nur" 10GB in der NC nutze.

    Der Papierkorb ist bei mir dann nochmal so ne Art "Fallback", falls ich mal was lösche, habe den also bei mir auf "120, auto" stehen.