Frank1940

Are you following this procedure? https://docs.unraid.net/unraid-os/manual/storage-management/#normal-replacement (Make sure that you are not missing step 6...) Oh, yes. You should not have lost any data as you have dual parity. The data of those two missing disks is actually available as these two disks are being emulated using the parity disks and the remaining data disks. That means you can both read and write data to them! When the disks are rebuilt, that emulated data will be written onto the new disks.)

How are you trying to rename these files? (If using command line, show the actual command that you are using to rename a specific file that fails.)

I would like to suggest that you post this request for help in the support thread for the Emby plugin/Docker that you are using. If it is a Docker, goto the DOCKER tab on the GUI and left-click on the Emby icon. In the dropdown menu, you should find a 'Support' link. For a plugin, goto the PLUGIN Tab and the link to the 'Support Thread' will be found within the Plugin's listing.

+1

Also try booting up in the Safe Mode (An option on the Unraid Boot Menu during bootup)...

Post up screenshots of these two commands run in the GUI Terminal: ls -al /mnt ls -al /mnt/user If you are concerned about privacy, you can crop the directory names off of the second one when you do the screenshot.

I am not sure what you are attempting to do but the syslog is stored here: /var/log/syslog

See the following screenshot from the GUI: Once you have gotten filtered out the lines you don't want, you can print it out. I doubt if a request was made to actually stop adding these lines into the syslog, I would not think such a request would even be considered. The Developers and Gurus (who assist folks on the forum) often use those entries to figure out what is going. Occasionally, there are some errors that introduce so many error messages that finding another problem becomes difficult because of all the 'noise'. That usually requires addressing the 'noise' problem not hiding it! Remember that messages that some process or device has started successfully is often useful when troubleshooting...

I hope your access to your Unraid server from WAN is through a VPN. (Unraid is not harden to survive more than a few minutes on the WAN without being hacked!) Now about the Ubiquiti network problem. This would be better addressed on the Ubiquiti user forum than here. (Personal note from a former Ubiquiti user--- Good Luck!)

Try setting the UMASK to 000 rather than 022 EDIT: And you will probably have to run the New Permissions Tools on the share(s) to which this Docker writes.

Make sure that you have set the following parameter: Otherwise, the copy may fail if the file won't fit into the space available on the disk chosen as the target. This setting is available for both Disk Shares and User Shares. Set the parameter for the type of transfer being done. (Most likely--- User Share...)

I am in much the same boat as @JorgeB. But here is a laundry list of things to look at and try... Is the WIN11 computer giving any sort of error message? What are the symptoms of the "crash"? (In my experience, Windows generally goes into a definite routine and 'calls home' to report what it consists 'true' crashes.) After a crash, try a Ctrl-Alt-Del and pick Task Manager from the dropdown menu. Look and see what is going on with the program that crashed. (Is it stopped or is it pegged at high percentage for example?) Have you tested the RAM in your WIN11 computer? How many clients do you have on this network? How many of these clients have this issue and are they all running WIN11? Are you overclocking any WIN11 computers? Can you arrange to get another WIN11 computer to test on your network to see if it has the same problem? Have you rebooted everything involved with the network? (Router, switches, etc.) Are you using Jumbo frames as these can cause problems?

A few years back, I had a brand new PS failed in the first two weeks after I installed it. As I remember, it was either spontaneously rebooting the server or shutting it down. Luckily, I was only doing an upgrade of the PS at the time. So it being the last thing I had changed, it became the prime suspect! (As a retired Engineer, I had learned in my career in that profession to make one change at a time and look for any problems that the change might introduce!) Thinking that a new component will always be good is not a justifiable assumption. Google infant mortality bathtub curve for insight into the failure modes of complex assemblies of components.

From the shareDisks.txt file in the "Shares" folder in your Diagnostics file. appdata shareUseCache="only" # Share exists on cache b----p shareUseCache="no" # Share exists on disk10 b-----s shareUseCache="yes" # Share exists on disk1, disk5, disk10 d--a shareUseCache="yes" # Share exists on cache, disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11 domains shareUseCache="prefer" # Share exists on cache D-------s shareUseCache="yes" # Share does not exist F-------e shareUseCache="yes" # Share does not exist g-------e shareUseCache="yes" # Share exists on disk5 i---s shareUseCache="no" # Share exists on disk5 isos shareUseCache="yes" # Share exists on disk5 l--------d shareUseCache="no" # Share does not exist M---a shareUseCache="yes" # Share does not exist M----s shareUseCache="yes" # Share does not exist M---c shareUseCache="yes" # Share does not exist N--------r shareUseCache="no" # Share does not exist n-------d shareUseCache="no" # Share exists on disk5, disk7 p------s shareUseCache="yes" # Share exists on disk1, disk5 P--x shareUseCache="only" # Share exists on cache_wdssd s---e shareUseCache="no" # Share exists on disk5 S----------y shareUseCache="no" # Share does not exist system shareUseCache="prefer" # Share exists on cache, disk10 t--p shareUseCache="prefer" # Share exists on cache T------s shareUseCache="yes" # Share does not exist U----------------------A shareUseCache="no" # Share does not exist U----------------------A (1) shareUseCache="no" # Share does not exist U----------------------w shareUseCache="no" # Share does not exist U----------------------w (1) shareUseCache="no" # Share does not exist U----------------------Q shareUseCache="no" # Share does not exist U----------------------A (2) shareUseCache="no" # Share does not exist U----------------------w (2) shareUseCache="no" # Share does not exist U----------------------Q (1) shareUseCache="no" # Share does not exist U----------------------w (3) shareUseCache="no" # Share does not exist U----------------------A (3) shareUseCache="no" # Share does not exist U----------------------g shareUseCache="no" # Share does not exist U----------------------A (4) shareUseCache="no" # Share does not exist U----------------------g (1) shareUseCache="no" # Share does not exist U----------------------g (2) shareUseCache="no" # Share does not exist U----------------------w (4) shareUseCache="no" # Share does not exist U----------------------w (5) shareUseCache="no" # Share does not exist U----------------------Q (2) shareUseCache="no" # Share does not exist U----------------------Q (3) shareUseCache="no" # Share does not exist U----------------------g (3) shareUseCache="no" # Share does not exist U----------------------Q (4) shareUseCache="no" # Share does not exist U----------------------Q (5) shareUseCache="no" # Share does not exist U----------------------g (4) shareUseCache="no" # Share does not exist U----------------------g (5) shareUseCache="no" # Share does not exist U----------------------g (6) shareUseCache="no" # Share does not exist U----------------------w (6) shareUseCache="no" # Share does not exist U----------------------Q (6) shareUseCache="no" # Share does not exist U----------------------g (7) shareUseCache="no" # Share does not exist U----------------------Q (7) shareUseCache="no" # Share does not exist U----------------------Q (8) shareUseCache="no" # Share does not exist U----------------------Q (9) shareUseCache="no" # Share does not exist U----------------------w (7) shareUseCache="no" # Share does not exist U----------------------w (8) shareUseCache="no" # Share does not exist U----------------------w (9) shareUseCache="no" # Share does not exist U----------------------Q (10) shareUseCache="no" # Share does not exist U----------------------g (8) shareUseCache="no" # Share does not exist U----------------------Q (11) shareUseCache="no" # Share does not exist U----------------------Q (12) shareUseCache="no" # Share does not exist U----------------------g (9) shareUseCache="no" # Share does not exist U----------------------g (10) shareUseCache="no" # Share does not exist U----------------------w (10) shareUseCache="no" # Share does not exist U----------------------A (5) shareUseCache="no" # Share does not exist U----------------------Q (13) shareUseCache="no" # Share does not exist U----------------------A (6) shareUseCache="no" # Share does not exist U----------------------A (7) shareUseCache="no" # Share does not exist U----------------------Q (14) shareUseCache="no" # Share does not exist u----t shareUseCache="no" # Share does not exist w---------k shareUseCache="no" # Share exists on disk1, disk2, disk3, disk4, disk5, disk6, disk7 Z------N shareUseCache="no" # Share does not exist You have 72 shares listed and most of them do not have a directory in the root of any physical hard drive! I counted only fourteen shares have even have a directory on a disk.

Quick look at your diagnostics. Two things. First thing, you have a lot of shares that do not exist on any storage media. (I would suggest deleting them as they merely make figuring out what is going difficult.) Second thing, you have not set up this parameter on the shares that I checked: It should be about double the size of the largest file you will ever store on this share. Unraid checks before it starts a transfer that this much free space is available on the disk where it proposes to write the file. If that amount of space is not available, it will move on to the next disk allocated to this share and write the file on that disk. Once Unraid starts the write if there is not enough space on selected disk, the write will simply fail. If this is not the problem, please provide the first and last characters of the share name(s) with the problem so as to simplify examining your diagnostics file.

I also owe you a bit of a apology. I was 'following' this thread and didn't realize that it was in the 'Active Directory' sub-forum. All of my experience is with the 'ugly-stepchild' of Windows Networking--- the peer-to-peer part of SMB. (Most of the Unraid users employ peer-to-peer networking and MS is more concerned with AD security--- and their corporate clients ---than with the small universal of people who use peer-to-peer.) Many of those 'home network' Unraid users are just not concerned about security and try use use peer-to-peer with as little thought to security as possible. When MS addresses a security issue that effects the corporate world, it often breaks those minimum security Unraid network setups. Then they scramble to find a solution to undo the security fix. (A whack-a-mole approach!) The Samba software team will update the samba code as required to address these changes. It is my contention, that all Unraid SMB/Samba users should employ a reasonably secure network setup. MS has and will continue to upgrade security to SMB on Windows clients as they deem necessary. If those security changes break some peer-to-peer networks that are attempting to run with little-to-no security on them, so be it. These SMB security upgrade issues can be avoided 99% of the time by just setting up the peer-to-peer network to be secure. This requires that no Windows computer will ever need to use a guest connection to a server. Every Windows will have a user name and password to access their Unraid server. It means that the network should be configured so that SMBv1 is not required for operation. (I might point out this eliminates the need for 'Public' or 'Secure' Security settings on Shares if one is using all Windows clients. The need for those two settings is often dictated by other devices--- like old Media players from the 2010 time period that only use SMBv1.)

Try setting up a Windows Credential (using 'Credential Manager') to that 'Share Access' user on your Unraid server. (You may need to reboot the Windows 11 computer after you do this...) There is a tutorial if you should need additional Info. See the first post in this thread: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/

As a completely side issue, I would checking that UPS battery. A drop in the voltage of the power feed to the UPS will usually cause a UPS to supply power to the load without a discernible drop in the voltage being supply. (I normally use enough incandescent light bulbs to require the UPS to deliver 200-300 watts of power. I would expect to continue to supply power for at least five minutes. If it doesn't, I would be ordering a replacement battery!)

What I would be doing is trying to link those 'names' of the non-IT MODE controller assigned to the actual serial number of the disk itself. (Depending on the controller, this could be simple or difficult...) Once you have done this, you would replace the card(s) and assign the disks using the serial numbers to the proper disk slot using the "New Config" TOOL --- setting parity as being correct. At this point, I hate to provide detailed instructions as I have never had to do this. It may well be in the Manual but if you can't find it or are confused, @JorgeB has provided guidance in the past. Do you have single or duel parity? With single parity, disk order is inconsequential and parity will be correct if all of the data disks are simply assigned as array data disks. With dual parity, parity is wrong if the data disks are not assigned to the same identical disk slot. I am a bit paranoid so one thing I would do is to run a non-correcting parity check before I started. Then I would run another parity check after I was finished. (I prefer addressing one problem at a time!)

These devices can be messy to use depending on how old they are. If they are old enough that they only support SMBv1, they are basically EOL devices and recent Samba versions often have to be browbeaten to get them to work. As I recall, if they work now on your current version of Unraid and you do a upgrade to the latest Unraid version, SMBv1 will still be 'active' ('Grandfathered' in) on your Unraid server. (If you do a new install, SMBv1 will be turned off (if I understand it correctly) and you will have to turn it on. With WIN10, it is best to establish a Windows Credential using Credential Manager. Of course, you will have setup a 'Share Access' user on Unraid. Doing this generally eliminates problems on both the Unraid side and the Windows client side. If you should run into a problem, read through the PDF in the first post of this thread: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/

Try spinnning up all of the drives first on the server. (It is the "SPIN UP" button' in the "ARRAY OPERATIONS" section of the MAIN tab. Unraid will do this but it always seemed to me that it does them one-at-time rather simultaneously.)

Be careful with this one since (as I recall) it uses 'free' memory to cache the information. If you are caching large numbers of files, it can run out of this memory and 'flush' earlier entries. It then will eventually refresh these entries. The result can be almost constant disk activity. Be sure to do a bit of Google research (using unraid.net as the first search parameter) in getting it setup as the Support thread covers all of the Dynamix plugins which results in a 'lot of noise' when going through it! (I do use this plugin but I only cache a single Share--- my Media files. There are less than 6000 entries which seems to work with my having 8GB of RAM.)

For future referance for anyone else who might have this problem, how did you fix the problem? Please describe in enough detail to allow that person to do it the same way as you did. (Example: Don't say "changed file name". Rather say, used Linux command, XX, from the command line using the Unraid's GUI terminal.) EDIT: And mark your answer as the Solution.

Quick look at the 628 Spec's did not shown any reason why you could not use this box. The only question is the RAID solution that is employed--- hardware or software. Unraid prefers that you use standard SATA ports. This usually requires that if you require a expansion card that it has the 'IT-mode' software installed on it. (A lot of the RAID cards with JBOD modes do 'funny' things with drive serial numbers which can cause issues in the future...) First thing to do is see if you can get the 638 to boot from a USB port. To do this, install the trial version of Unraid onto a USB drive. You can find instructions here: https://docs.unraid.net/unraid-os/getting-started/quick-install-guide/ From the guide: Just making sure that the 628 will boot up to Unraid will not do any automatic or background writing to the existing disks in the 628 box! (Unless, you start assigning disks to the array and attempting to start it. Remember that you are just verifying that you can get the 628 to boot.) You can access the GUI on your PC. You may need to open up the 628 box and see if it has a hardware RAID card in it. If you do this, try to figure out what the card's maker and model number is.

I also requested that you do this: I would recommend installing the Unassigned Devices plugin and format the external media to be a format that can be read by either your Windows PC or your MAC. Plug it into the appropriate client and copy it back to Unraid using SMB. The purpose of this exercise is see if it will find some files with naming issues. If either copy fails on a file. Figure out a way to avoid trying copying it.