All Activity

That's all very odd...i am aware of the Disk 9 Write caching and I am adding and replacing drives very frequently lately the go file has been like that for years without issues. almost all of it is commented out the docker-shell is just a small script that lets me via via CLI press a number to access any running docker containers cli it was introduced by spaceInvader1 some years ago. the log file was set set larger to accommodate some issues i had a long time ago. I do not have IPv6 enabled on my network or unRAID so that's very odd. I am using IPvlan as MacVLAN had issues a version or two back. eth0 is my 10gbps NIC and eth1 is the on board 1gbps NIC i would think nothing is wrong there since its been working for just over a year in this configuration. either way its something that recently happening and hasn't since the last recovery....very odd

Wireguard is built into unraid and is my go to for accessing my server from a phone or another computer. It also allows you access other machines on the same network.

My experience is exactly the opposite, I have Deluge running for many weeks before restarting, and have no issues when restarting the container from the dashboard in unraid. I used to do what I had mentioned and use quit and shutdown, and it did not restart itself...I'm not sure what init changes were made that may have changed this behavior, but consider I believe it ran with -d it shouldn't restart the daemon, I had a crash a few days ago during some testing of some stuff, and the daemon didn't relaunch. deluge-web kept running but was not connected to any daemon, the two are not mutually exclusive. Edit: If you want to stop the daemon from the webui, go to connection manager, and select the daemon and hit stop daemon.

Apologies for dragging this up again, cleanly shutting down deluge seems to have been a problem since it's inception lol. I have managed to 'Quit & Shutdown Daemon' from the windows client as mentioned above (does option not exist in the web client?), which seems to have resolved most of the issues I had previously with stopping the docker container from unraid. The issue I'm having now is that the daemon restarts itself. So if I need to shutdown the container for whatever reason I have to 'Quit & Shutdown Daemon', wait long enough that it shuts down cleanly, but not too long or it will have started again. I assume there's something in the Binhex container that's recognizing that the process is no longer running and starting it up again? Can I stop this somehow?

这可能得等12小时左右，我在重建校验盘，有结果了我在回复

那你之前的问题没有描述完整，现在尝试重置一下硬盘插槽：工具-新配置-勾选阵列插件重置 然后去共享重新添加设置，拆分级别：自动拆分，包含和排除的硬盘都要指定

UPDATE: I fixed the playback error part, even though i did this a couple times, i once again deleted the Codecs folder and started the server again and it started working. I would still like to know if the whole old version of server is normal, or if i need to do somethign else to get it updated. Thanks. Hi, question, Plex has been running great but all of a sudden i seem to be having issue playing back some media, even stuff i was able to play like 30 mins ago. I added a new movie to my collection and went to play, and after a few seconds of trying to load, it came back Playback Error. I then tried to play a movie i just watched, and same issue. Its a mixture of things that will play and things that wont. I did a restart and update to the latest version of unraid. I am using linuxserver resp and noticed that while it says updated on April 18th, and no update availble in docker, on the plex server, it shows im running version 1.31.3.6868 and latest is like 1.40. Is this common, i dont really recall as since installing, i never had to worry about it.

并不是，以前的版本文件夹Disk_Media包含了磁盘2 3 4 5 6 7 8 这个文件夹内的文件夹只要建立在哪个磁盘就会往哪个磁盘写入文件，现在的情况变成了在2磁盘建立文件夹 却写到了3我是从6.12.4升级到6.12.10的 6.12.4是可以这样的

I noticed this: Apr 26 14:54:22 streamengine kernel: PANIC at space_map.c:405:space_map_load_callback()

你的设置明显错误，根据你的描述，应该是要把文件夹Disk_Media指定存储在disk2。那么正确的操作应该是： 从一级导航 共享 下新建目录Disk_Media 拆分级别默认自动拆分即可 包含磁盘勾选disk2，排除磁盘disk1和disk3 补充一下，从文件管理器里disk2下新建的文件夹不会自动聚合在/mnt/user/

Support assisted with a license transfer, now at 3 days uptime on new flash drive.

Hey sorry for the delay on this, I would very much like to get you up and running. Unfortunately I will need some logs from Mover Tuning which don't get saved with the diagnostics zip. If you follow the steps here in #1 to get the logs that should allow me to figure out exactly what is going wrong Don't worry about doing 3 runs, just the 1 should be fine.

My log is full of entries that say: vnstatd[6292]: Traffic rate for "docker0" higher than set maximum 1000 Mbit My network is 10Gb/s with 5Gbps ISP load. I know this is likely a setting somewhere for statistics but I can not seem to find where.

I tried this, but I must have typed something incorrectly. This did fix it, thanks!

试过了，删除了所有的，只保留了disk2里面的文件夹，可是依旧在disk3新建了文件夹写入了disk3

I haven’t read it yet but am now. I’ll let you know if I have any questions. Thanks for the link.

I am unable to login. I enter the correct user name, password and used the server address of clients.us2.crashplan.com Is there anything I can do to get crashplan working?

There is on invokeAI (option 3) under settings enable nsfw checker.

Yeah it seems my template changes haven't made it to those who already have it installed you need to add these variables: Variable: CONDUIT_DATABASE_PATH - /var/lib/matrix-conduit/ Variable: CONDUIT_PORT - 6167 Variable: CONDUIT_CONFIG - leave empty

The latest update seemed to have broken it for me: thread 'main' panicked at src/main.rs:53:55: The CONDUIT_CONFIG env var needs to be set. Example: /etc/conduit.toml note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Das geht ohne Probleme. Dazu musst du nur den Pfad im Docker zusätzlich einrichten, so das Plex das auch Mountet. HIer ein Beispiel: Macht Sinn Ja, du kannst soviele Mounts einrichten wie du willst.

Ja, und genau das ist ja auch der Grund dem Array einen Pool mit SSD(s) vorzuschalten Die Parity bei einem Array mit mehr als 2 Festplatten bremst eben. Naja, Du bist mit 2 Paritydatenträgern sicher gegen den Ausfall von maximal 2 Datenträgern im Array. Wenn das die gesuchte (Ausfall)Sicherheit ist: ja. Gegen so gut wie (fast) alles andere was passieren kann bist Du damit nicht sicher. unraid selber kann BitRot nicht erkennen oder gar beheben. Es gibt ein FileIntegrity Plugin, welches ich aber nach Tests nicht mehr einsetze. Ich setze auf halbautomatisch (über ein Windowssystem) erzeugte Checksummen um in späteren Prüfläufen zu erkennen ob da etwas nicht mehr stimmt. Wenn es Dir das bringt, was Du willst: okay. Naja, "um jeden Preis" ist eine vielleicht doch sehr teure Sache. Aber dann wird es wohl Zeit für diverse gespiegelte Systeme auf der Welt.

Ist zwar eine Share Einstellung, aber ja, die wirkt sich auch auf die zugeordneten (bzw. nicht ausgeschlossenen) Disks aus. Ich gebe zu, ich verstehe die Frage nicht so ganz, aber die oben gemachte EInstellung betrifft nur das Array. Für Pools (SSDs) kannst (und solltest) Du extra nochmal einen Minimum free Space einstellen. Wenn Du Daten von außen beispielsweise per SMB hoch lädst hat ein Docker damit nichts zu tun. Wenn Du eine 300GB große Datei hoch lädst bekommst Du bei der Einstellung ein Problem. Der Minimun Free Space sollte immer größer sein, als die jemand zu schreibende Datei. Wenn Du hingegen viele kleinere Dateien hoch lädst, die in Summe 300GB haben, dann wird unraid so lange den Pool/SSD beschreiben, bis eben die 100GB unterschritten werden. die nächsten ganzen Dateien werden dann (wenn man de nicht irgendetwas falsch eingestellt hat) nicht mehr in den Pool, sondern in das Array direkt geschrieben. Plexeinstellungen sind nicht so mein Ding. Ich plexe nicht. Was Du in einem Plex Container einstellen kannst, weiß ich nicht. Das Docker Image ist immer nur auf einem Laufwerk. Man kann Docker auch nicht im Image, sondern in einem Verzeichnis laufen lassen, aber auch das liegt eigentlich auf einem Laufwerk (das aber vielleicht auch zum Teil von dem Pool in das Array rüber schwappen kann). Aber eigentlich ist es ja so, daß die Container für Docker sehr klein/schlank sind und somit der Dockerkrempel kaum Platz bedarf. Aber Du kannst den Containern (mit vielleicht 2 GB Platzbedarf) ja Zugriff auf diverse Shares geben, doe dann einige hundert TB groß sind. Und diese müssen ja auch nicht unbedingt Shares sein, die auf physikalische festplatten verweisen, sondern können auch auf physikalischen SSD liegen, die vielleicht permanent auf einem extra Pool liegen.