Boergen

Hi, This container stopped working for me. Without changing anything (besides doing the Docker updates), the container stops after a few seconds with the following log: *** Running /etc/my_init.d/10_syslog-ng.init... Oct 9 21:16:46 ce6d4dcd662e syslog-ng[19]: syslog-ng starting up; version='3.25.1' *** Running /etc/my_init.d/arm_user_files_setup.sh... cp: not writing through dangling symlink '/etc/arm/config/abcde.conf' *** /etc/my_init.d/arm_user_files_setup.sh failed with status 1 *** Killing all processes... Updating arm user id from 1000 to 99... Updating arm group id from 1000 to 100... Adding arm user to 'render' group Oct 9 21:16:48 ce6d4dcd662e syslog-ng[19]: syslog-ng shutting down; version='3.25.1' ** Press ANY KEY to close this window ** Has anyone else encountered this and/or can provide a possible solution? Thanks, Boergen

Hi, this may be a dumb question.. How do I set the --device setting? I cannot find the setting in the GUI and it is not presented in the Docker settings during setup. ##EDIT## I'm indeed dumb. Setting is available in "Advanced View" in the Docker settings.

Just wanted to share that the latest scheduled (quarterly) parity check ran without any issues over a course of 10 days. I also updated the plugin versions in between. This is only the second time it worked without manual intervention, so hopefully the latest changes helped with restarting a paused check reliably.

Hi, For me, the Parity Check Tuning plugin only ever worked successfully once. Every other times, it paused (due to temperature) and never resumed. When checking today (it's currently hanging again), I saw the following log spam: Jun 11 13:06:25 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:12:42 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:18:46 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:24:43 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:30:35 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:32:12 unraid emhttpd: spinning down /dev/sde Jun 11 13:32:12 unraid emhttpd: spinning down /dev/sdc Jun 11 13:36:36 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:42:22 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:48:32 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 11 13:54:44 unraid crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null I also attached my diagnostics. Could you maybe take a look at what's going on? Thanks and best, Boergen unraid-diagnostics-20230611-1357.zip

Hi all, asking for a friend... for real, as I already own an Unraid server. A friend of mine is interested in Unraid, but he questions the security of plugins. For Docker, we both understand how security works in that regard, but we are unsure about plugins. So the concrete questions: What prevents a potentially malicious plugin from being posted (and thereby installed) in the plugin repository? If a non-malicious plugin becomes malicious through an update... would that be caught somehow? Maybe an explanation on what a plugin is or is not actually allowed to do would be helpful, as well as a short summary of a potential plugin review process. Thanks a lot!

Hi, I very much would like to know this, too. Though I'm 90% sure it's seconds, a specific unit in the description would indeed be helpul.

Yeah. After some painful consideration, I'm inclined to go with this and paint a big "RTFM" on the server case. Copying with disabled cache works as intended: The files get split according to the "high water" setting. I'm pretty sure some media files exceeded the min free space setting for the cache and that's where it went sideways. Sorry for dragging you into this and thanks for the support.

Hi cheesemarathon, and thanks for your quick response. I think the cache setup itself is not the issue. I also think that I get how it works (not meant offensively). I copied from an external samba share to /mnt/usr/media (media is my media share, set to "high water" with 2 disks). So I did not copy directly to a specific disk. The cache was used (as was intended), but when the cache filled up to 100%, the copy processed stopped with an error. I would have expected that the copy process just continued with writing directly to the actual disks (which would be normal behavior for a copy process to a cached array). The question is... when is it determined where the files are actually written onto? Start of the copying process for all files Whenever a new file is copied (that would be the expected behavior). If 1) is the case, then that probably explains my issue: The first files would fit onto the cache, but the rest won't, so an error occurs. Say you start a copy process for 5TB, each file is 100GB and the target is large enough, but with a 200GB cache. When you normally copy something to the array, the first 2 files are copied to the cache and the rest is written directly to an array disk. With Cloud Commander, it seems like it wants to copy everything where the first file would fit, circumventing (skipping?) the balancing check that usually takes place for each file when you copy something to an unraid share via SMB (e.g. from a Windows PC). It may of course be possible that copying to /mnt/usr/media is not the correct way to do it if I want to use the balancing feature.

Hi all, I have a small issue with Cloud Commander: I want to copy files from a SMB share to my cached Array. This is what I did: Set up the shares via the Unassigned Devices plugin and mounted them. Started a copy of 3 large (~5TB each) folders to my Array. The process aborted with an error stating that the target space was full. I checked and sure enough... the cache pool (240MB) was full. So it seems that a Cloud Commander copy process is not handled via the usual array balancing process. Can I even do this kind of transfer with Cloud Commander then? If so.. how? Thanks and best, Boergen

Hi mgutt, danke für die Antwort. Ich denke, Du meinst dann den RTL8156 oder etwas in der Art? Zumindest soll der ja ab Kernel 3.2 unterstützt werden. Werde ich dann einfach mal ausprobieren.

Hallo zusammen, ich stelle derzeit die Hardware für meinen Umstieg von Synology auf Unraid zusammen. Hat jemand Empfehlungen für einen in Deutschland erhältlichen 2.5Gbit USB Netzwerkadapter, der Out of the Box mit Unraid funktioniert? Danke und Grüße, Boergen