The rebuild for the second drive finished earlier this morning. I clicked around through some share folders, wrote some data, accessed some data, and deleted some data, and everything seems alright.
I believe that my troubles were mostly related to something on Thursday, from the initial logs. A problem with my HBA seemed like the most feasible thing, and to me, seems like the likely point of failure for the system anyways. I am going to order another HBA, and some 8643 breakout cables, and keep them handy. The drives themselves are entirely fine, and I did not need to switch anything out.
Thank you for the help.
Edit so I can tag this as solved;
I read through my logs, and with the help of the comments above determined that there was an intermittent issue, likely with my Adaptec ASR-71605. I plugged the problem drives into the motherboard via sata, and rebuilt using parity data. All is OK now. 👌
Thank you @Frank1940and @JorgeB for your thoughtful comments. I was already on the right path yesterday and found the source of my issue, which was actually exactly what you two had guessed.
Previously, I had set up my UnRaid server to use active directory, though I recently switched off of it due to poor implementation. To my understanding, what that would have added in are more granular ACLs, controlled by the active directory administrator, rather than by UnRaid. After I learned what the "+" meant, and how to check ACLs with getfacl, I found my solution, which you may read below.
---------------------------------------------------------
As mentioned in my initial post, the permissions were set to "-rw-rw----+", with "+" indicating that there is an access control list for the directory. To me, this means that the "users" group could potentially have "---" permissions within this ACL, which, once I checked, there was.
Command used at terminal;
> getfacl New\ folder <-- created "new folder" as "brad" user in windows
Summarized response from terminal;
> "group:users:---" <-- Previous assumption that the ACL was blocking was correct
So, to fix my problem, I need to properly set the ACL. I first tested this within a test share, set to "secure" with all users given read and write perms, as follows.
> cat /etc/group <--- Used to find what the GID is of the "users" group
> users:x:100: <--- GID is "100", which will be used in setfacl
Map test share as "brad" on device. Create folder named "folder" via windows file explorer. Check ACL via terminal on server
> cd /mnt/user/testshare
> getfacl folder
Note how there is a user with a bunch of numbers. this is the active directory administrator. I'm simply going to ignore that user for now, as the admin should have perms anyways. The problem currently lies with "group:users:---", disallowing the users group from accessing the folder. Also, "default:group:users:---", which will make this non-access ACL propogate whenever new folders are created. I then changed the default ACLs and the ACL for the folder to allow the "users" group access with the two following commands:
> setfacl -m g:100:rwx folder <--- Sets the users group on the folder to be allowed read, write, and execute
> setfacl -d -m g:100:rwx folder <--- Sets the users group to be allowed by default on this folder, and any content created within the folders.
Now we check the ACL of the folder to see if everything is alright.
> getfacl folder
Everything seems good, so I mapped the test share as user "John" and was able to read and write from the folder that Brad had created, and when I went on my other system previously set up for Brad, he was able to read and write anything John had created. All works well. So, now I just have to recursively write ACL changes to any of the shares experiencing the problem, aka all of them. Before I do that, I want to make sure I know how to do this recursively correctly, so I went into the test share again, and made a new file called "testfolder", and within that, a folder called "recursivefolder", and a file within that called "recursivefolderfile.txt". Then, I went back to my terminal and tried the following commands;
---------------------------------------------------------
>setfacl -d -Rm g:100:rwx testfolder <--- I had previously messed up putting the "R" elsewhere. It must be BEFORE the modifier "m", or it won't work. Not sure why.
>setfacl -Rm g:100:rwx testfolder <--- Must also set the non-default, or the current. This will apply to the files within the folder, as those don't have defaults, they simply inherit them.
>getfacl testfolder <--- All good, as my previous fix above.
>getfacl testfolder/recursivefolder <--- All good, recrusive functionality is working for folders
>getfacl testfolder/recursivefolder/recursivefolderfile.txt <--- All good, recursive functionality worked for files too.
Now I recursively set this on my actual use folders, using the setfacl commands "setfacl -d -Rm g:100:rwx [foldername]" and "setfacl -RM g:100:rwx" after cd /mnt/user. This solved my problem.
Another potential problem that I realized is that /mnt/user was causing any new shares created to inherit these incorrect ACLs, so I changed that as well. I don't want any non-authenticated users to be able to access data on my unraid server, so other will be set to --- for my setup.
> cd /mnt <-- Places us in the easiest spot to write the next command
> setfacl -d -m g:100:rwx user <-- Fixes the "user" shares area of UnRaid for future use. Essentially will be "Secure" for any shares created.
I found the solution to my problem. The Unraid Server will not be considered to be disconnected from the Active Directory until it has been rebooted.
I had not rebooted my server, so I waited for a good time, then tried that, and it worked. I then had to go into the unraid terminal through the gui, and make sure that the "root" user had ownership of the base directory of the user shares to make sure that UnRaid's GUI features would work correctly again.
I just want to be done with this thread, so I'll say what I'm doing to get around this here, and mark it as my solution. I already know this will work, but I wanted to learn a more proper way to do this, hence the rabbit hole I went down. If anybody ever finds a solution to this problem, please leave a reply on this thread for others to see.
I'm genuinely disappointed with the Active Directory implementation in UnRAID. I love the operating system for what it is, and everything aside from these permissions has been a breeze. Setup was easy, configuring plugins was easy, the forum is very helpful, and everything is documented in a way that makes it easy to understand. I didn't really have a better alternative that wouldn't have been some ungodly expensive Microsoft product, so it was worth a shot. Regardless, here's what I'm going to do;
I'm unable to access my files when the "root" user creates them with any commands like rsync, and I'm not aware of a way to log in as an active directory user in the terminal, since I can't log in as my UnRAID users, so I'll be doing the sinful method of transfer with file explorer one transfer at a time to make sure ownership is from my active directory account. I have approx 6.8TB of data, though a lot of it is in computer images, which tend to be larger in size, so almost half of the data will write sequentially, so it shouldn't be too awful in practice, just tedious.
Create new shares and start fresh for those, to ensure that permissions aren't borked from my previous activity on them. I'm probably not going to copy all of my old data, as this is a great opportunity to organize and get rid of what I don't need.
Evenimous's post in Disk Disabled, Cannot Figure Out Why was marked as the answer