Frank1940

Tell us about your Windows side of the equation--- Windows 10 Pro, 23H2, etc. Make sure that your Windows Network Profile is 'Private' and not 'Public'... (Many of these problems are on the Windows side of the equation. MS caters to the corporate world and to them security is paramount. MS is now dedicated to keeping Windows clients from connecting to any suspicious server!) There is a white paper about how to set things up for Windows 10 and everything in there seems to work for Windows 11. You can find it in the first post of this thread: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/ Since you seem determine to not to post up information because of privacy concerns, you may have to work through things on your own. Unraid will work reliably in the Workgroup mode if both Unraid and the Windows clients are set up correctly. (Using Active Directory is definitely more of a challenge!)

CRAP! I forgot one thing! Go to SHARES Then Click on each share tyou want to access with that user (that yoiu setup in the previous post: Scroll down until you find these sections: Step 1 --- Set the Security you want for this share. (You can click on "HELP" icon on the GUI taskbar for help with the settings!) Step 2-- Set the Access for that share for each user. Step 3-- Click "APPLY"

Try creating a Windows Credential using Credential Manager for that new user and user password that you used for the mapped share. (You may have to reboot the Windows computer to test...)

The permissions on Directories should be 777 and on Files 666. For access from Unraid shares, (From my experience on recent releases) is that the owner of a resource is not the key, it is the Group (which Unraid expects to be users and that any user who wants to have access to a resource must also be either the owner or a member of users. The easiest way to become a member is to added as a 'Share Access' user under the USERS tab of the GUI. Futhermore, all Dockers apps (and, I assume, VM's) that write to Unraid Shares should have these parameters as follows: This information comes from this posting: https://forums.unraid.net/topic/131730-update-from-69-to-6115-and-got-permission-denied/#comment-1219731 EDIT: Actually in a secure environment, much of the access to a share will be through being a member of the Group. That is way why it is necessary for the members of the Group to have full access to any resource.

You never really stated how you shutdown your Unraid server or how you found that the flash drive had failed. One of things that happen when Unraid shuts down gracefully (or 'cleanly'), it sets a flag in a file on the flash drive to indicate that the array was shutdown properly. (i.e., all of the cache buffers were flushed to the platters on the hard disks.) When your drive failed (or was corrupted), this flag may not have been set (or you didn't restore the file that contains the flag.) What happens when Unraid boots up is that it checks for this flag. If it does not find it, it assumes that parity is not correct and offers to rebuild parity. The GUI informs you that starting the array will start a parity rebuild. (Long experience has shown that this is usually the best option for most unclean shutdowns if all of the data drives can be mounted.) This rebuilding parity check may or may not find any parity errors. (There were discussions in the distant past as to whether it might be better to run a non-correcting parity rather than a parity rebuilt. The problem was that if the non-correcting check found an error, it was almost impossible to find a cause-- and a solution --to fix the problem. So a slow consensus was reached that rebuilding parity was the way to go. That way, if there was a subsequent disk physical failure, that disk could be rebuild without a loss of the data on that disk--- Even if there was a data problem on another disk, that first disk with the failure could still be successfully rebuild. If there was a case where parity could not be rebuilt, the disk with the problem would be revealed and that issue could then be addressed!) I would assume that all of your data on the data drives are OK unless there was a disk write operation going on when you actually shut the server down. Most of the time, data losses occur when the server is forced down by a power failure. I can not recall a data loss from a simple flash drive failure-- unless there was subsequent cockpit error. One thing you should worry about is assigning a data disk as a parity disk. (Rebuilding parity onto a data disk will result in data loss.) But I would assume that you have already figured out (or knew) which drives were your data drives! If you don't, state so as there are ways to figure things out.

Here is the section in the Manual about replacing the flash drive: https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/ Not that I am aware of. Unraid in its basic configuration is fairly hardware agnostic. However, once you are using VM's, you will probably have to change things if you are passing hardware through to the VM. (If you pass hardware through to a Docker, the same warning will apply. Much less likely with a Docker but I would bet there are a few Dockers which do use passed-through devices.) OH, make screenshots of the tabs for disk assignments, network setup, Docker, plugins setups, etc. If you do, you will never need them... 👿 If you need more help, please provide more details about what you currently have and what you are doing with your present setup. Then tell us what you would be proposing to do with the new setup.

So what are those permissions? (A screenshot using ls -al command in the Terminal GUI would be very helpful.)

Try writing a file size larger than 5GB. Depending on what the process is that is figuring your write speeds, the time may include a lot of time that is not actually the file transfer itself but may include things necessary to set things up for the transfer. Unraid Share file allocation process is particularly slow as it adds another layer of software to the normal Linux file creation. I looked at your shares and it appears that you are caching writes to your shares. Normally, using a SSD (or NVME) cache drive for a share will take good size files speeds close to 1Gb/s speeds. Also try using the 'Write-reconstruct' option as shown below: IF trying these does not work, post back with what you tried and what were the results. One more thing, have you checked the speed transferring a large file back to your PC?

Have a look at CA User Scripts plugin which can be found by searching APPS tab...

Many long years ago, I had a transfer problem from Windows to my Unraid server. I spent the better parts of two months trying to figure out what was happening. One of the things I finally tried was to update the Realtek driver on my Windows computer. That fixed the problem! This solution is one that it probably outside of the 3-Sigma limit but it is something to consider. (Just be sure that you go to the MB manufacturer to check to see what version they recommended for your MB. Update if they have a later version.) RealTek has had driver problems for years. Windows is generally better off than Linux but they are the low-cost supplier of NICs and their driver software fits that niche.

From a Google search:

Try Windows Explorer as a test for these files rather than Teracopy.

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