bonox

Danke für die schnelle Antwort. Diese Antworten habe ich bereits erwartet. Meine unausgesprochenen Vermutungen wurden bestätigt. Paritycheck ist ohne Fehler durchgelaufen. D.h. somit die Parität passt zum aktuellen Stand ohne die Daten. Im Syslog habe ich nichts gefunden. Es sind ja nur Filme. Es ist nicht das technische Problem die Filme wieder auf die Platte zu bekommen. Es ist vielmehr die Zeit, die dafür benötigt wird. Ja, ich werde mir wohl Gedanken um ein Backup-System machen müssen. Die Disk mit den schlechten Werten, werde ich schnellstmöglich austauschen.

Guten Tag allerseits, vor einigen Tagen habe ich schmerzlich feststellen müssen, dass über 400 meiner Filme verschwunden sind. Die Filme liegen auf einem SMB Share und werden in aller Regel über Plex geschaut. Plex läuft als Docker auf Unraid. Den genauen Zeitpunkt wann die Filme nicht mehr vorhanden sind weiß ich leider nicht. Ich musste vor ca. ein bis zwei Wochen den Unraid-Server per Unterbrechung der Stronzufuhr neu starten. Die Unraid-GUI war nicht mehr aufrufbar und die Docker Container haben auch nicht mehr funktioniert. Nach dem Neustart konnte ich eigentlich keine Fehler feststellen. Die Container laufen alle wieder wie gewünscht und konfiguriert. Lediglich habe ich, wie bereits beschrieben, vor zwei Tagen die fehlenden Filme fesrgestellt. Andere Daten fehlen nicht, soweit ich das überblicken kann. Auffällig ist, dass auf Disk 1 nur 31 Filme vorhanden sind. Auf Disk 2 hingegen 228. Ebenfalls auffällig ist, dass bei Disk 1 der SMART-Wert "Reallocated sector count" orange hervorgehoben ist, da der Schwellwert 50 mit dem Wert 48 unterschritten wurde. Ein SMART-Short-Test wiederum wurde ohne Fehler abgeschlossen. Den erweiterteten werde ich jetzt noch anstoßen. Disk 1TOSHIBA_MD04ACA400_55TGKB5SFSAA - 4 TB (sdf) Disk 2ST4000DM004-2CV104_Z9702Z4N - 4 TB (sdd) Cache CT1000BX500SSD1_2323E6DFA2A9 - 1 TB (sdc) Flash DataTraveler_80 - 31 GB (sda)*61981670vfat31 GB Sdb ist eine USB-Platte, welche lediglich an eine Ubuntu-VM weitergeleitet wird. Gibt es Logs, in denen nachvollziehbar ist, was genau passiert ist? Gibt es die Möglichkeit die Daten über die Parity-Disk zurück zu bringen? Ist es sinnvoll eine 4 TB Platte durch eine neue zu ersetzen und auf die Wiederherstellung per Parität zu hoffen? Besten Dank vorab und Grüße Sascha

Hi dlandon, thanks for answering super fast. You are right. Mapping was wrong. I did the change and now I'm able again to upload files. But why did it work for years with apparently wrong settings? Anyways thanks for great and fast support.

Hi all, after upgrading unraid to version 6.12.3 2023-07-14 I'm no longer able to upload, delete or change files. No matter if I try it by web ui or mobile apps. Last log entry is from 2023-08-02T18:36:13+00:00. That means logging stopped from that point. By the attampt to upload a file via Android app I can see a push message telling me it is not possible to upload due to insufficient rights. I checked with ls -l /config -> But most directories and files underneath have root:users. Only a few have abc:users Is that correct or has it abc:users as well? BR, Sascha

Did anyone solve this problem? Facing the same.

same question over here. I want to open this proxy page encrypted by using https. Is that possible?

Thanks for responding quickly. I restart the container very rarely. I'll keep it in mind to check the logs. Checking the logs actually should be the first thing to do Don't ask me why I did not do?! Might be that I thought the docker log is enough .....

Another question: How can I restart the oscam service on command line? I need to restart oscam periodically.

Owncloud is up and running. It just took very long. I guess more than 30 minutes. Any explanation for that?

Hi all, I tried to upload a file with a size of approximately 1.6G. It failed. Even when I set client_max_body_size to 0 in the config files under server and http. I reverted everything back to the values before. Now the docker stuck at '*** Running /etc/my_init.d/60_get_owncloud.sh...' during the boot process. The config files I found does not tell me anything related to the boot process. Has anyone had a similar situation and can give me a tip? In case this has alreaby been discussed, sorry, I did not read all the 16 pages due to lack of time. Many thanks in advance BR, Sascha

Same question over here.

Until today I did not know about the recommendation to update owncloud manually. In the past I used the auto updater many times without any issues. This time I'm facing a 504 Gateway Timeout error. That's why I'm here Current version is 10.9.1.2 All former updates up to version 10.9.1.2 went fine, as already mentioned. This time it seems I have to go the gard way. dlandon mentioned that the auto updater will fail. What is the reason? BR, Sascha