Clink

The updated version works fine now, thank you. For some reason your container plays better with my set of plugins.

SafeInCloud, despite its name, supports self hosted WebDAV.

I like that I can ssh in and mess things up. I would like to see an apps and services focused Unraid for ARM.

I had the same problem. Unfortunately I am not sure what fixed it, but I suggest going to the VM Manager Settings page, enabling the advanced view and making sure all settings and paths are valid, even the ones you don't use (like Windows drivers). Restarting the VM Manager via the web GUI might not work, because it consists of multiple components and the start/stop commands can abort early if it is in an inconsistent state. At least the command: /etc/rc.d/rc.libvirt restart did not work for me. I modified the script to allow restarting anyway, but rebooting the server is probably easier.

I have had this problem in a mixed ReiserFS/XFS system; converted all drives to XFS and no shfs lock ups since then (a couple of weeks now). Of course it could have been some weird file/directory structure inconsistency situation that went away when the files/directories were newly created during copying.

That cable won't work for your situation, you need a 'reverse' cable like this one: https://www.caseking.de/silverstone-sst-cps03-re-sata-zu-mini-sas-kabel-50-cm-zusa-206.html

Just out of curiosity, what are its advantages/differences to TTRSS?

The "Calculate all sizes" folder option is also worth checking - sometimes I forget that I set it earlier & wonder why everything is so slow.

Can you connect the scanner via WiFi? I find it quite liberating to just plug in power and scan some documents away from the computer.

For me, one drive redundancy during normal operation is fine - the likelihood of data loss due to fat fingers etc. is much higher than due to a drive failure (finger widths may vary). However, replacing a drive or shrinking the array currently leave the array unprotected during the operation, unless one is happy to juggle cryptic 'dd' commands. The preclear script is already a great way to extend the array without losing parity protection, and I would love to see something similar, perhaps even fully integrated in the GUI, for the other array config changes. The aim would be to have one drive redundancy at all times.

I am pretty sure this is not a credentials issue, so don't bother trying any login combinations. Review the share access right settings, or log into your server shell and do a "ls -l" on the directory giving trouble.

This works, write speed is back to 50+ MB/s. Terrific - thanks Tom. Is it ok to put this into my go script?

Another data point. System RAM is 16GB. Boot into 5.0-rc8a; array is off-line Write test to an unformatted non-array drive: speed is good (>100MB/s) Start array in maintenance mode Write test to the same unformatted non-array drive: speed drops to 850kB/s So just starting the array has a profound effect on non-array drives. I am not sure why my system slows down with 16GB while others see an improvement when downgrading to 16GB. The tunables are set to 4096 / 1024 / 1280 (md_num_stripes / md_write_limit / md_sync_window).

My system is showing similar symptoms as moose's, with even lower write speeds of around 500kBps; the hardware is different (SAS card is LSI 1068e based, motherboard is an Intel dq57tm). It makes no difference whether the data drive is connected to the card or to the motherboard; the parity drive was always connected to the latter. copy via console shows the same speed, so it isn't network related hdparm shows all disks at 100+ MBps (except flash of course) rebuild parity speed is good (80 to 100 MBps) read speed is good (60+ MBps via network) 5.0-beta12a has good write speeds (~30MBps) extras loaded were unmenu and samba 3.6.8 on the rc8a setup the syslog shows nothing worth of note (and nothing at all during the cp /dev/zero speed tests) Currently I am back to 5.0-beta12a and everything is fine. In all other ways the upgrade to 5.0-rc8a was uneventful except for the more strict samba user rights checking.

Good advice. I can confirm that beta13 and beta14 exhibit the "not ready" problem on my system whereas beta12 and 12a are fine. So it seems that the Linux LSI driver no longer waits for a drive to spin up?