Frank1940

Make sure that you reboot all the LAN devices---router and switches. Some folks have had issues if they attempt to use Jumbo MTU's (Best to stick to 1500 which is the default.) This type of problem occurs so seldom and I can't recall that a single thing being the cause/solution. Tell us what is on the sending end of these failures-- OS, Ethernet NIC, file manager, etc. It looks like you have an Intel 1Gb NIC in your Unraid server. Have you tried a second PC to see if it has the same problems?

First, go to SETTINGS >>>> SMB >>> SMB settings and verify that SMB is enabled: Then go to the SHARES tab. Click on the SMB Share you want to connect to. Find this section on that tab: Step # 2 is where you 'allow' the share to be exported. Step # 3 is optional but I recommend that you consider using 'Private' rather than 'Public' or 'Secure'. There should be no reason for either of these unless you are connecting with a Windows 98 computer or a Media box from 2010. Step # 4 is where you set the permission for each user-- Choices are 'Read/write', Read-only' and 'No Access'. If you need help in setting SMB, here is a link to a PDF tutorial: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/

The SATA connector is the Poster Child for how not to design a connector system. It is very susceptible to vibration and to being loosened when the cable is disturbed by being moved. (I would not recommend tying SATA cables together to 'dress up' the interior of the case as this can subject all of the cables in the grouping to displacement forces when one cable is moved for any reason.) Personally, I would not open the case to check the cables with only one error. You might cause more problems then you 'fix'. If you ever do check the cables, make sure that they are all seated. Do it twice being very careful on the second check. And do everything-- both ends, Data and Power.

No. A UDMA error is a communication error between the drive and the MB. The connection is serial data transmission and it has a CRC check code embedded. The error message indicates that the transmitted CRC code did not match the code calculated by the receiving device. The data block is then re-transmitted until the codes match. So there is no hard error that would result in data loss! Most of the time (when there are hundreds of errors in a very short period of time), replacement of the SATA data cable with checks to make sure that the SATA connectors are fully seated is the standard procedure. In your case, you can click on that error icon (can't remember if it is right-or-left click) and acknowledge the error. You will be notified if it happens again. (I had one disk with 1823 CRC errors on it for over two years and the count never increased after that initial burst. I did replace it when I needed more storage space a few months ago.)

Try one thing. Spin up all of the drives in the array before you start the next transfer of a big file that would normally fail.

@TowerOfPower, any possibility that the server was hacked? (It sounds like you are accessing it remotely...)

RAM is about the only thing that can be easily checked to see if is good or bad. Most other hardware is 'tested' by replacement. That is why clues to things that are not 'normal' are important. You want to start there. The order of replacement process is often governed by the cost of the replacement component and its ease of replacement. You can do this. Start by googling live windows version and build a boot-able flash drive. When using it, read everything that comes up before you click 'OK'. You do not want to allow Windows to do anything with your Unraid drives!!! (By the way, don't be surprised if Windows shuts down after a few minutes.)

I can recall hearing stories of pumps in dishwasher and clothes washers where the blades on the impellers in the pumps were almost completely eroded away! Things do wear out and everything ever made to do 'work' will eventually fail-- requiring repair or replacement. One can make statements about the probability of failure for large populations of an item but they do not apply to a single sample of that item. You are best to assume that anything and everything in that computer is a suspect until you have verified that it is working properly. I am not saying that anything is defective but an indication that the CPU temps are hitting 90C is a red flag that I would be pursuing. If that temperature is correct, the prime suspect would be a failure somewhere in the cooling setup...

Start by Googling max cpu temp Then figure out if the temperature shown by the plugin is accurate. You could also google the water cooler you are using and see if others have had any problems with it and what those problems were. (A water cooler is a much more complex system then an air cooling setup and thus has more points of failure.) You might consider pulling the cooler off and renewing the thermo paste. (I am assuming that you have not overclocked this system.)

You have single parity--right? And the only thing running was a parity check or a RAM test... If that is the case, I would not expect to see those temps on an Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz CPU. (You can run a single parity check on a single core processor from 1998 at full speed. That is how much CPU power it requires!)

This could be worth looking into. If your system has been running for months, most likely the cooling pumps and fans have been running all the time. It could be that when they stopped this time, they could not restart. Remember that the water in the cooling block probably takes a long time to cool back down to room temp if it does not get circulated through the cooling fins.

IF this behavior continues, Consider setting up the Syslog Server using "Mirror syslog to flash: " method. After the next shutdown, pull the flash drive and get the file from the /logs directory/folder and upload it in a new post in this thread. EDIT: One more thing, make sure that all fans are running. Another thing. Is a parity check running? Do you run periodic parity checks? If so, how often?

I am not an expert on NFS but have a look here: https://forums.unraid.net/topic/151505-you-require-permission-from-nobody-to-make-these-changes/#comment-1355922 and https://forums.unraid.net/topic/57507-private-nfs-share-mounts-without-userpass/#comment-1359758

Read here: https://docs.unraid.net/unraid-os/faq/licensing-faq/#what-happens-if-my-usb-fails-do-i-have-to-repurchase-a-license

Basically, ask this question in the Jellyfin Docker support thread. You can find this by going to the DOCKER tab on the GUI. Then click on icon for Jellyfin and pick 'Support' from the dropdown list. You did double check that the files were actually missing off of the array and not from the Jellyfin database? (I would recommend installing the Dynamix File Manager plugin using the builtin APPS feature...)

Bu the Diagnostics file begins on Dec 10th and the last entry is on Jan17th. The ZIP file itself has today's date embedded in the file name. What are you defining as a power outage and when did it occur? Is your server on a UPS? Did the server actually shutdown? (From your description, I would have expected that the syslog would have started when you powered your server backup, it would contain recent bootup entries, and would show some recent events--- such a login from the GUI.) Since you are using a RAID controller, there are no SMART reports on any of your drives. (A common issue with RAID controllers...)

What happens when you click on the 'View' icon for disk6? (Circled in the quote above...) Do you have a recent backup of your Boot (Flash) drive?

I export my flash drives but they are 'Private' and normally read-only (This setting allows for reference reading as I do a lot of support help here on the forum). If I require a write operation, I go in via the GUI and make the share read-write to do any necessary operation. Then back to read-only! You really don't want to over-expose your boot drive!

An off-the-wall question. You have 19+ disks in your server. Does it have a single-rail power supply that can provide 45-50 amps of +12volts for those drives?

NO!! At this point, it appears that disks 5 and 6 are being emulated and all of their contents are available. Be patient and work through the questions and steps that you are being asked about and how to proceed. (In fact, those old disks may well be intact with all of their data safe! There are are a lot of things that can cause a disk to become disable that are not related to the actual disk itself!)

If you are using SMB, you can set the following parameter: You then have to 'know' the path to the share to be able to access it. (If you set the share to Private and use a reasonably strong password, you will have done more than to secure the share than trying to 'hide' it.)

I think the default setting was 'Yes' until relatively recently. (I can't remember when this was changed but it could not have been too far in the past as there have been several cases of this problem recently and I don't recall this being the case in the distant past. I also seem to recall that I actually went into all of my shares on both of my servers and turned off access to NFS and SMB to any share that was not being accessed via those protocols!) I suspect that this new default applies only to 'new' shares. Any existing shares were not affected-- a 'Grandfather' situation.

@JorgeB, if @jkwaterman did this, how could it be a browser issue...

@JorgeB, any thoughts?

Stop all Dockers and VM's and prevent them from starting automatically. Reboot the server to the 'Safe Mode' (an option in Unraid's Boot Menu) and see if that works.