tyrindor

This has never worked for me. I have 20 disks and it always says 16 are spun down even though I have them all spun up. If I manually enable turbo write, it'll disable it because it thinks too many drives are spun down.

Its not "slow" as in that slow. I just have gigabit internet and I prefer my usenet client to go 100MB/s, not 10MB/s. First world problems, eh? I'll try his VPN version of qbbittorrent thanks.

My VPN is pretty slow and I don't want to slow down the other tasks I use it for. However, I don't want my IP broadcast on my torrent client (qbitorrent) docker. I can't find a way to do this, other than installing a virtual machine and having the virtual machine setup to use my VPN. Not ideal since I don't need a whole virtual machine running and using resources.

Thanks, it was my syncthing log files. I deleted them and enabled docker rotation.

Woke up today and it was 9.99GB of 10GB, but I know just last week it was only 5GB. I don't see anything wrong with my paths and I checked each docker to make sure nothing was linked to the docker itself... Any idea what's causing this? I've tried sending test files through radarr/sonarr/nzbget and it doesn't increase. Had to do a syncthing database rebuild this week, so I suspect that's the cause, but why would syncthing be storing anything in the docker itself.

I am still not seeing any caching taking place. If I disable it and re-enable it, there's no reads on any of my disks. Just going into random directories results in low amount of reads. When cache directories was working, I'd see it go through my disks 1 at a time and produce a fair amount of reads when I started it. Something possibly wrong with my settings?

All sorts of issues with this lately (I'm on unRAID 6.6.3). Constant reading all drives even though nothing is being accessed, not starting up on restart (despite the changelog saying that was fixed), and the removal of scanning user shares. Scanning user shares was necessary or I'd get constant spinups on my setup. Tested it many times prior to it being removed since the plugin always claimed it wasn't needed. Please add that feature back. I have tried adding -u but it still seems nothing is being cached despite it "running" and my shares selected. Every time I go into a folder I get reads on the disk. I think it started happening after 6.6.3 update but not positive.

Done. Thanks.

Just finished clearing 3x 12TB on 6.5. Everything is fine but the log is filled with warnings. See my post here:

Getting a lot of these in the log, don't remember seeing them before updating to 6.5. Any idea what's causing them? Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte11h - assumed 'byte11h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte10h - assumed 'byte10h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte9h - assumed 'byte9h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte8h - assumed 'byte8h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte15h - assumed 'byte15h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte14h - assumed 'byte14h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte13h - assumed 'byte13h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:21 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte12h - assumed 'byte12h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte11h - assumed 'byte11h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte10h - assumed 'byte10h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte9h - assumed 'byte9h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte8h - assumed 'byte8h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte15h - assumed 'byte15h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte14h - assumed 'byte14h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte13h - assumed 'byte13h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte12h - assumed 'byte12h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant ID_MODEL - assumed 'ID_MODEL' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant SERIAL_SHORT - assumed 'SERIAL_SHORT' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 470 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte11h - assumed 'byte11h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte10h - assumed 'byte10h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte9h - assumed 'byte9h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte8h - assumed 'byte8h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 662 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte15h - assumed 'byte15h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte14h - assumed 'byte14h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte13h - assumed 'byte13h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663 Apr 5 04:25:22 UNRAID rc.diskinfo[8036]: PHP Warning: Use of undefined constant byte12h - assumed 'byte12h' (this will throw an Error in a future version of PHP) in /etc/rc.d/rc.diskinfo on line 663

I've been using unRAID for around 8 years, and until lately I haven't had speed issues I couldn't fix. I have poor read speeds as well now, and I don't know if it started on 6.4 or 6.5 or earlier. The problem seems to come and go, sometimes I get 160MB/s on my 10G nic and other times it's 10MB/s. This is on great hardware, quad core Xeon with 16GB off DDR3 1333.

I have 3 12TB drives preclearing right now, so it's gonna be awhile before I can look into this further. I really don't get what I am seeing right now though. I am now getting piss poor 10-20MB/s reads from the majority of my drives as I try to transfer stuff off them. These drives are connected to 3 different SAS2LP controllers on a Supermicro X9SCM motherboard with a E3 v2 Xeon processor. I want to blame the fact they are "archive" drives, but archive drives shouldn't have any issues with reads and I never had these issues in the 2 years of owning them. RAM usage is 13%, CPU usage is <10%. Writes are fine (160MB/s) and my 3 Preclears are going 270MB/s each, so I don't think it's an interface/SAS controller issue. I am unable to test parity speeds until my preclears are done, but the last 16 month I finished with an average of ~180MB/s, so I doubt anything has changed. These slow reads seem to also be happening when using a program like Syncthing, which to my knowledge wouldn't be using SMB at all. I'm puzzled, seems like the problem comes and goes and only affects certain things.

Do you think I should disable jumbo frames on my 1G connection then? I am using 1G to a switch/router, and 10G is a direct link between 2 Mellanox ConnectX-2 controllers. I was actually gonna try disabling jumbo everywhere and see if that's the issue, but haven't got around to it. I can transfer to my SSD cache at 600MB/s, so I doubt it's the 10G network though. For whatever reason, my server seems to suck at multitasking despite having a quad core E3 v2 Xeon. I blame the fact I am using archive drives, they seem to bring the entire system to a chug whenever they are being wrote too. This doesn't happen with my new 12TB drives.

I am currently running no parity drive (temporarily!), as I do a lot of disk to disk transfers and restructuring/organization. I am on 10G with jumbo frames set to 9000 on both the windows 10 PC and unRAID. DirectIO is enabled and I am forcing SMB2_02 because in the past everything else has been very slow. All disks are the same speed - 8TB Seagate archive drives. If I do "move cache" I see 160MB/s from cache to disk, but if I do a disk to disk transfer I see about 50MB/s. These are all large 30-50GB files. The drives are much faster than this, and benchmark at about 160-200MB/s read and writes. I am barely getting faster than I did with parity enabled... Why is SMB slowing it down so much?

Thanks! Took me a bit to figure out, gotta enable advance view in the docker and set -e UMASK_SET=000 under extra parameters.

Same... there's no way to set permissions to 0777 in this like sonarr/nzbget/etc. Anything this program downloads I cannot modify via my SMB share. Is there no solution?

I'll be running this on 3x 12TB drives later this week. I will report back if there's any issues.

Awesome, just in time thanks.

Preclear no longer works with the latest unRAID, and I have 3 brand new 12TB drives I need to test. I obviously don't want to test these one at a time because it'd take ages, and connecting them up to my HTPC would be a headache since I don't have any spots. Is there no way to test drives in unRAID prior to clearing them and adding them to array? I'd like to do at least 1 full write, followed by 1 full read.

What? I've been here since very early.. when unRAID was very non-user friendly. The community is growing rapidly, and the software and site is incredibly better. With dockers and VMs, there literally nothing you can't do on an unRAID server.

I got this up and running and most of the time it's fine. However, every now and then it'll download a file and not give it the correct permissions (need access from nobody). I have umask set to 000 as suggested in the OP. This only affects some downloaded files, majority are fine. Any ideas?

I ran it again, and now that I have 2 backups in the same folder I can select which backup. Seems when you only have 1 backup it shows "No backup found", probably just a display issue. Great tool this will save me a lot of time.

Backup settings/directory were never changed since I backed up. It should be reading from the same directory it exported too. What do you mean by "tar"? I don't see anything like that in the folder it created.

I just started using this and backed up everything (it made a folder called "[email protected]" and inside that a "CA_backup.rar" file). However, if I go to the restore tab under "Select a backup set to restore", it says "No backup sets found". Is this because I only have one backup?

Having the same issues as hus2020, the appdata/syncthing folder cannot be access via Windows (Windows 10 Pro x64 in my case) even though permissions are 99/100 (default). I have also tried forcing a umask of 000. The docker itself works fine, unRAID can access everything. If I want to back up the appdata, I must run a permission script on the folder, and then when I relaunch the Syncthing I lose access to that folder again. Edit 1: Just set this up on my friends server, and his has the same problem. I wonder if it has to do with a custom appdata directory? I use a share called "Stationary" which is a cache only share. The share is set to "Secure", with 1 user having read/write. EDIT 2: To clarify, this does not happen with your qBitorrent, Sonarr, and NZBGet dockers.