betaman

Ok got it. Like I said, the icon to format the disk is what confused me. I’ll preclear it and leave it unassigned or remove it. When I do have to assign it then it will be formatted. Thanks.

If I add it to the array then it becomes part of parity. When I go to remove it won’t UnRaid want to rebuild my parity drive? However, since the drive is just precleared, I don’t think it affects parity and I can override the rebuild but am I crazy in thinking/remembering that in the old days of the Joe L script, I could preclear a drive without adding it to the array? Edit: Maybe we’re saying the same thing. My goal is just to stress test this disk so I know it’s ready in case of a problem.

Disk is “added” but unassigned. I want to preclear the disk so it’s ready in case of a drive failure. I just don’t remember seeing the format notice on a device before but I haven’t added or precleared a drive in quite some time! So the order of operations is preclear, format, assign?

Just read thru last couple pages of this thread. Seems like everything is taken care of (known bugs anyway) but was looking for some confirmation before clearing a 10TB drive with this docker. Also, my parity is currently rebuilding and the new disk is unassigned and not formatted. I guess I need to wait to stop array and format or does the preclear script also do this per my disk setting (ie MBR 4K aligned)? I think I found my answer In FAQ: Alignment Options (-a and -A flags) Below is the logic built into the preclear script when determining the starting sector for the partition:- if preclear -a option chosen and drive < 2.2TB then will set to 63. if preclear -a option chosen and drive > 2.2TB then will set to 64. if preclear -A option chosen and drive < 2.2TB then will set to 64. if preclear -A option chosen and drive > 2.2TB then will set to 64. if preclear -a or -A not defined then 63 or 64 will be chosen based on unraid config, UNLESS the drive is > 2.2TB, in which case it will always be 64.

I have this scrolling issue with the dashboard tab. Docker tab works fine. Affects all iOS devices running iOS 14.2 and Safari or Chrome.

I was having same issue. Tried multiple ovpn configuration files with the q22 change. First the cipher error then when I changed locations it was still expecting the old file (still haven’t found where this setting is as I’ve forgotten from when I set it up previously). Anyway, I just deleted the entire openvpn folder contents and copied the .cert, .perm and .ovpn files again this time using same region as I had started with (Czech Republic) and voilà, it worked. 🤷🏼

Is support for nzbgetvpn dead? Is there another alternative for vpn with an nzb downloader? Edit: I just deleted, reinstalled and reconfigured docker and it's working. No idea what changed.

Damn...was hoping it wasn’t just me. Just curious if yours was working and then stopped suddenly? And in theory, why couldn’t these two containers use different VPN servers?

My nzbgetvpn stopped working with vpn enabled. I’m using PIA and latest docker release. Anyone else experience this and have a solution? DelugeVPN still working correctly as usually if it is a PIA issue they break together.

I remember flashing FW but knock on wood, I think most of my “red ball” issues are related to my backplanes or cables.

I rebuilt parity. Here's the short SMART test report. Do you see anything I should be concerned about? tower-smart-20191017-2122.zip

Thanks for the quick response. Is there not a good preclear tool for the current release? What do you suggest I do to determine the state of the failed drive? Also, can you tell anything from the diagnostics about the significance of the errors?

I had a drive go down last night. Syslog showed some errors. I captured the Diagnostics (attached) but was unable to get the drive to show up after several start/stops of the array. I just went ahead and replaced the drive since I had a spare handy but was hoping to get some feedback on my next steps. The drive is still rebuilding now and I'm currently out of SATA slots in my server. With the higher capacity drive I used, I could copy over data from a smaller drive to the new one as well so I can put the failed drive back in the machine and do SMART tests and run a pre-clear. The issue is I'm not sure of the best process to reduce the array by one drive. I remember a long time ago do this without losing parity but not sure that's still an option in the latest version of UnRAID (6.7.2)? I checked the FAQ but I wasn't sure if it was updated with the most current best practice for doing this? Several of my drives are old so I'm a little concerned about being uprotected while Parity rebuilds. tower-diagnostics-20191015-0231.zip

Did you add this to the latest container or do I need to create the variable first? I don’t see it currently. Thanks.

Ok, thanks. What server did you specify for PIA? I found US-Midwest to be the fastest one for my connection.

Not a lot of activity here but will ask anyway. Is anyone using NZBgetVPN with PIA and getting download speeds above 10MB/sec (assuming you have a faster internet and news host connection) since the change to PIA's port forwarding capabilities? If so, which server are you specifying? I can only get faster speeds now by disabling VPN service. Thanks.

I have the 4096 cert file presumably because strong certs was enabled. I don't remember why I enabled this in the first place so dropping back to the 2048 version shouldn't be an issue? It doesn't look like my strong cert files are being updated when I pull a new version of the docker (i.e. files are from 2017). EDIT: I was able to get this docker working again by doing a clean install and then copying the correct cert files in the openvpn directory.

Thanks, this worked for me as well. I agree it doesn’t make sense that reverting to an older version fixes the problem.

Can you please screenshot your /config/openvpn/ directory? I tried Switzerland as well to no avail.

I tried option 1 but it didn't work for me. I also didn't see a variable for STRICT_PORT_FORWARD in my settings. Is this because I have an outdated template? EDIT: I also noticed more than one file in the /config/openvpn/ directory. Is this an issue? I tried removing the openvpn.ovpn file but no change.

Thanks for the response. I had to do an unclean shutdown. No obvious cable issues. I rebuilt the drive last night and it has been running ok since. I guess I'll just keep an eye on this HBA.

So I tried stopping the array and it seems stuck at unmounting disks. Not really sure what to do at this point?

Hi guys, I haven't been on the forum lately because well, I haven't had any issues with my UnRAID server! Anyway, just got a red ball on my disk 1 and was looking for some help troubleshooting what went wrong and how best to proceed from here? I did look at the smart report for the affected drive (5XW024TM) and didn't see anything alarming but like I said, haven't done this in a while so looking for some expert opinions. I also noticed the sd#'s don't match between the smart report labeling and what I see on my dashboard (e.g. failed drive is sdw in report but sdi on my dashboard) so not sure if that matters? Thanks in advance. tower-diagnostics-20180606-1102.zip EDIT: I just noticed that I have write errors to several disks as well. I think it's related but can't be sure. Please let me know if any additional info is required. The syslog is repeating these errors over and over: Jun 6 10:41:31 Tower kernel: mdcmd (11848): spindown 2 Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower kernel: mdcmd (11849): spindown 4 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower kernel: mdcmd (11850): spindown 5 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower kernel: mdcmd (11851): spindown 9 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write Jun 6 10:41:31 Tower kernel: mdcmd (11852): spindown 10 Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower kernel: mdcmd (11853): spindown 12 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower kernel: mdcmd (11854): spindown 14 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write Jun 6 10:41:31 Tower kernel: md: do_drive_cmd: lock_bdev error: -2 Jun 6 10:41:31 Tower emhttpd: error: mdcmd, 2639: No such file or directory (2): write

Yeah, I got that now. Problem is I didn't know about it beforehand. Would be nice if there was a toggle in the built-in permissions script but I realize it was really meant for one-time use.

So I was having an issue with my Emby app (for AFTV) as well as web playback. I can't be 100% certain but I believe the root cause was the New Permissions utility changing the attributes of two files. I ran the utility on my cache disk because one of my dockers assigned attributes that wouldn't allow me to copy the file from the cache to the server manually from a Windows VM. Basically, I think it removed the executable attribute from ffmpeg and ffprobe (i.e. from -rwxrwxrwx to -rw-rw-rw-). Once I did a chmod 777 ff* to these two files, Emby started working again. What made the matter most confusing is I wasn't having any issue with Kodi playback using the Emby addon. I presume this is because Kodi has its own playback engine and wasn't relying on the ffmpeg install from Emby but I could be wrong.