wyee

@limetech If I change over to the 6.9-beta would I be able to roll back to the 6.8.3 version without corrupting my data on all disk drives? Also you mention to make sure to enable Enhanced macOS interoperability. Are you assuming my problem report above was for using Apple iOS devices only? I am having the slow wake up response problem on Windows 10 OS, Android devices. Will going to the 6.9-beta version fix that too? One last question, are you just guessing that this will fix the issue and want me to just try it or are you sure it will fix the slow wake up response issue? I don't want to risk causing problems corrupting my Unraid system by migrating to a beta and then have to roll back in case something incompatible happens and I lose disk data.

Folks, I too have been experiencing this very slow opening of share directories when I click on my Unraid shared drive directory it takes a very long time to list out the directory contents. The disk that the shares are on is already in a spun up state (not sleeping) so it's not due to disk wake up spin up delay. I am currently on the latest Unraid Version 6.8.3 2020-03-05. I am very unhappy with this performance as it is frustrating to always have to wait for Unraid to access my shared directories. Yes there are directories that contain thousands of files in them. But still the performance really stinks on Unraid compared to my FreeNAS server with the same backup directory shares and content. FreeNAS wakes up and shows the drive contents almost instantaneously while Unraid takes minutes to wake up and show the directory contents listings. I am a paid Unraid user and I wish that they would get to the bottom of this and fix it. if FreeNAS works properly to list huge file directories quickly, then so should Unraid. Please fix this annoying bug.

Nevermind, I found the problem and fixed it. I suspected that something might have gone wrong with my Ethernet LAN driver settings that made it not work with unRAID connections. So I plugged in a Wi-Fi USB dongle adapter I had on hand to connect to the network via alternate interface and path. I disabled the Intel Ethernet adapter and connected with the Wireless adapter. Bingo, no problem at all connecting back to my unRAID server and also successful at browsing to the unRAID GUI interface. So after that I uninstalled the Intel Ethernet adapter driver and reinstalled it to reset any config settings that the Windows updates might have affected to it. After removing the USB Wi-Fi dongle and rebooting back on the Ethernet LAN connection, wala! it now is back to normal and can connect to my unRAID server again as normal. Problem solved.

For those thinking that this does not apply to a possible unRAID bug... I should mention that on the problematic Windows 10 Pro PC that fails to connect and access the unRAID server, the PC can access all my other NAS server devices. The other NAS servers I can connect successfully to are WD MyCloud, ReadyNAS Duo, ReadyNAS NV+ and a FreeNAS server. The only one refusing to cooperate with this Windows 10 Pro PC is the recently updated v6.2.4 unRAID server. Something must have changed in the unRAID update that is causing the failure to connect. I am thinking it is credentials or some sort of certificate authentication related that might have changed and become incompatible between the new unRAID update and the new Windows 10 updates. Anyone have any ideas what might have caused this?

Hello, I am experiencing a strange problem just recently. I had allowed my unRAID server to auto-update to the latest unRAID releases this past week. After that I started experiencing problems with one of my Windows 10 Pro PC's where it can no longer access unRAID shares nor can it even get to the web GUI. It is behaving oddly where before it was having no problems all. The windows 10 pc did get a cumulative security update on 11/08/2016 which I have uninstalled and hidden using a Microsoft utility that Miocrosoft provides. The Windows 10 Pro 64bit PC is not updated to the latest Windows 10 Anniversary edition. It is still at Windows 10 version 1151. Here are the symptoms: 1) Using File Explorer the unRAID server shows up under networks along with my several other NAS servers. I click on the unRAID servername and it shows all the drive shares as normal. But when I click on any of the shares to access its contents, that's where it sits there with the green progress bar slowly moving along at the top of the screen. It never recovers at this point. 2) Using any web browser (IE11, Chrome or Firefox), I enter the http://<ipaddress> of the unRAID server to login to the web GUI. It displays the login window where I enter credentials as I do normally and hit enter. After that, it hangs with the progress bar or indicator spinning forever. It never accesses the unRAID server. I have to kill all the proicesses to exit out of the explorers. 3) I have tried removing the old Windows logon CREDENTIALS from the Windows 10 PC and relogging in new. Still same hang. Still cannot get access connection. Yes, my workgroup names all match up on all my servers so it's not that. Remember this PC was accessing the unRAID fine just a few days ago before any updates. 4) Most noteful is that all my other PC's and android devices can still login and access this same unRAID server just fine as normal. It is just this one Windows 10 PC that something changed between it and unRAID protocol that has broken it. I am trying to find out what it might be. It is pointing to something on this particular Windows 10 PC since all my other Windows 10 PC's can still connect and access the updated unRAID server. When I kill the hung process of the Web Browser session on the Windows 10 PC, I see the following syslog messages logged in unRAID: Nov 9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe Nov 9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe Nov 9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe Nov 9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe Nov 9 10:52:38 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:52:38 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe Nov 9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe Nov 9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe Nov 9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe Nov 9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/font-awesome.css: Broken pipe Nov 9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe Nov 9 10:59:26 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 10:59:26 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe Nov 9 11:00:44 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe Nov 9 11:00:44 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/font-awesome.css: Broken pipe Nov 9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe Nov 9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe Nov 9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe Nov 9 11:00:45 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:00:45 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe Nov 9 11:00:54 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:00:54 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-fonts.css: Broken pipe Nov 9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe Nov 9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe Nov 9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe Nov 9 11:10:07 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:10:07 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe Nov 9 11:24:54 SERVER01 kernel: mdcmd (42): spindown 2 Nov 9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/font-awesome.css: Broken pipe Nov 9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/jquery.sweetalert.css: Broken pipe Nov 9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/default-white.css: Broken pipe Nov 9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/javascript/dynamix.js: Broken pipe Nov 9 11:26:34 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 11:26:34 SERVER01 emhttp: err: sendFile: sendfile /usr/local/emhttp/webGui/styles/dynamix-white.css: Broken pipe Nov 9 12:43:33 SERVER01 kernel: mdcmd (43): spindown 2 Nov 9 12:43:37 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 12:44:02 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected Nov 9 12:44:06 SERVER01 emhttp: err: need_authorization: getpeername: Transport endpoint is not connected I see the mention in the log entries about need authorization... so what in Windows or unRAID changed to cause that? and what is the fix?

I mounted the old 3TB disk1 drive anyway and looked at the contents and it seems a lot of the files and directories are missing from it from what remember should be there. I think that the drive was indeed corrupt before the unRAID rebuilding. So when I rebuild the new 8TB drives from these old 3TB drive images, they just copied the corruptions over to the new 8TB drives. But that still leaves me with the question on how did my 3TB drives become so corrupted in the first place. My unRAID server for the most part is hardly accessed or used that much with really very little activity other than the times I login to the GUI and see updates and let it update automatically on its own. I've read about flaws in the reiserfs file system causing corruptions in certain situations. Maybe my server encountered one of those situations, I don't know. I am now thinking of moving away from reiserfs format and trying to reformat to XFS.

I've installed the Unassigned Devices plugin and it shows my unmounted 3TB drive. But there is nowhere that I see for selecting to mount the drive as "Read Only". How do you do that with this utility? Do I have to write a script to tell this plug how to mount the drive? I only see a button next to the listed drive that says "mount" at this time. I would guess the default is to mount the drive full R/W which I don't want to do at this time.

Okay, so I have connected my old #TB disk1 drive to a free sata3 port now and stopped the array. In the webGUI I can assign it as disk3... but I can't find anywhere in the configuration screens to specify mount it as Read Only. Can I use the GUI to mount this outside of the array or must I use CLI commands? I don't want to add this old 3TB disk1 drive into my current unRAID config where it keeps showing up even after I remove the drive after testing it.

What do you mean I am not doing anything to troubleshoot this? I am performing the disk checks and parity verification checks on the current 8TB drives and all passed okay. Then I want to now mount the old 3TB disk1 drive to verify if those files are intact on that original drive and also run the reiserfschk on it. I am doing these checks a step at a time... In looking at the suggestions in post #5, one item does stand out to me that might have caused the file corruptions. That is where it says this: - user/disk copying bug - a file destroying bug caused by copies between a user share and disk involved in the share (creates the files with zero bytes I believe, something you could check) * Other than the last one (the user/disk copy bug), there aren't any reports of this happening, so I don't as of yet believe this is an unRAID bug. As I have mentioned I do have PLEX Server installed and it has defined shares of several of my disk1 directories with the same directory names. Some files that were corrupted are in some of those shared directories but then other corrupted files were not at all in a named shared directory. Anyway, I am about to mount the old 3TB disk1 drive and see how it looks.

Okay, I am beginning to think that the original 3TB drives were corrupted somehow now. I will try to mount the old 3TB disk1 drive to see if those files are okay or also corrupted before the rebuild. If they are corrupted, then I still have a concern on how unRAID corrupted all those files when the unRAID NAS is hardly ever used short of occasional PLEX server access to my shares and occasional writing some files to the unRAID disk1 drive. As far as I can tell, the 3TB drives setup was working fine before I performed the drive upgrades to 8TB drives. Something along the way might have caused the 3TB drive corruptions and I don't know what step along the way might have done that. I run no apps or software on this server at all other than PLEX. I am wondering if letting the unRAID GUI perform the automatic software updates including unRAID new version updates can cause disk corruptions due to some incompatibile setting between versions that could have occurred. Question: to mount my old 3TB drive along side my 8TB array drives, do I just plug the 3TB drive into a spare SATA3 port and mount it from the GUI or must I issue the CLI command from console terminal to mount it outside the array in order to view its contents?

I just noticed that on my Disk2 drive that many other file types I thought were unaffected are indeed corrupted too. That is I just found that my .txt, .jpg and .doc are all corrupted also on this drive! So it seems to not be limited to file types that got corrupted. I do understand how the Parity drive is backing up the disk drives. What I was trying to convey in earlier statement is the part that someone mentioned that the Parity rebuilds the data bit for bit on the new drive(s) and then it zeroes out the remaining space on the larger drives. So I was talking about that zeroing out part of the process... which might have somehow lost track of the indexing and zeroed out all these corrupt files. I say that because when I use my hex editior to view these corrupt files all of them contain all zeroes for their contents! Bug? Can it be something with unRAID upgrading from old 3TB drives to new larger 8TB drives and losing track of the index spacing somehow? Anyone else actually did what I did moving from 3TB drives to 8TB drives? Just wondering.

I ran the parity check last evening and it completed in about 12 hours 45 minutes with 0 errors this morning. I am running the reiserfschk (read only mode) now on my 8TB data disks. Data Disk2 report completed with 0 errors and no corruptions. So the disk seems fine. I am now running the check on Disk1 and I suspect it too will be fine. This tells me that the Parity Disk that was built from the original 3TB Disk1 and Disk2 drives image is probably corrupt. I will have to reinstall those old 3TB Parity drive and Disk1 drive to check and see if they had a corruption situation before I replaced them. Update: Disk1 reiserfschk just finished and reports no errors nor corruptions. All disks are fine. This tells me that whaterver image that got built to the new 8TB Parity drive is most likely corrupt. I looked at several of the corrupt files on my Disk2 drive using a hex editor and many of the files that can't be opened contain all zeros (0)! I wonder if that routine to zero out the rest of the drive during disk rebuild might have a bug.

Hi, I appreciate everyone's suggestions above. I don't have the time to go through all these long time consuming procedural checks right now but will keep it all in mind. No I do not have the original Disk2 drive in its original Unraid data contents or format as I have installed it in another Windows 10 PC already and reformatted it NTFS for Windows use. I do have the original 3TB Parity and Disk1 drives untouched. I am myself an IT professional software developer and I am familiar with Linux command line commands. I have not run any diagnostics disk checking commands on these drives as I didn't want to affect any changes on them just in case. I have not run RAM memory tests either. I have 16GB RAM installed on an ASUS H87I-Plus mini-ITX motherboard with an Intel I5 CPU. I will one day go through all this down time testing and verification of the old 3TB disks when I can afford to. In the meantime, I have already begun and copied restored all of my critical files back onto the Unraid 8TB Disk1 from my other backup copies and all files once copied back over to Unraid are opening and reading back fine. Yes, to the question asked that only certain file types seem to be corrupted (.pdf, .exe, .tar, .zip, .png) while other file types seem to have not been corrupted like (.doc, .txt, .ini, .java, .log). Also, NO file size does not matter on which files were corrupted. They are all different sizes both very small and very large. And yes, both new 8TB drives (Disk1 and Disk2) had the same kind of file corruptions all over the drive in every different folder and subfolders. It does not matter where on the drive the files were placed. I don't recall exactly what previous version of Unraid was running before I had let it update to v6.2.x versions. I am pretty sure it was version unRAIDServer-5.0.6-i386. Hope this info helps in any further diagnosis ideas. Also if it matters, I had these plugins and apps installed, Dynamix webGui, Nerd Tools, Preclear Disks, docker, plex. I can't remember off hand whether I had installed the "Nerd Tools" and "Preclear Disks" plugins after removing the old 3TB Parity Drive or before I removed it and installed the new 8TB Parity Drive in order to run preclear on the drives. I am wondering if this might have had the corruption effect possibly or if it should not have mattered.

Hi, I did not use any Unraid beta versions. Never have. All the drives were default Unraid ReiserFS format. I have not run any of the diagnostics on them. I have two of my original 3TB Unraid drives untouched since I removed them (the Parity drive and the Disk1 drives). I saved them just in case the new 8TB drives were bad. The 8TB drives are not bad and are working fine. I have already begun overwriting back my files on the 8TB Disk1 to restore them... So I don't think running a diagnostics on Disk1 will give a true indication of its state when all the files were corrupted. Also, Yes, the new 8TB disk2 also has the same file corruptions after it was rebuilt from Parity drive. Can I just mount my old 3TB Disk1 and Unraid will read it to check if the files can be read from the original files?

Hello, I have been using Unraid NAS for a couple of years now with three 3TB drives. Was working fine all this time. I then had to upgrade to three 8TB drives which I have done. Took about a week and a half to let all the drives rebuild. Then I first had upgraded to the latest v6.2 Unraid version. Before I replaced each drive I ran the preclear on all of them successfully.Then I removed my original Seagate 3TB Parity drive and replaced it with a new larger Seagate Enterprise NAS 8TB drive and let it rebuild the Parity drive. After it reported successful completion of rebuilding the Parity drive, I proceeded to remove and replace Disk1 and let it rebuild. It reported successful completion also. Then I proceeded to remove and replace my final Disk2 and let it rebuild. It too reported successful completion. I didn't think anything more of it and thought all was successful. File listings showed all my original directories and files all there on each respective drive. So I thought cool all went well. NOT! Today, I just noticed that when I go to pull my .pdf documents from the Unraid drives, that just about all of them will not open in Adobe Reader and report that the file may be corrupted! And indeed they all are. This perturbs me immensely. I am a paid subscriber to Unraid and thought it a reliable NAS system. Now I have my doubts and concerns as to its integrity and reliability. Luckily I have most of my .pdf files backed up and stored on my other PC's and other older Netgear ReadyNAS NV+ server disks and can recover them. I recopied these .pdf files from my Windows PC over to the new Unraid disks to restore them and see if they were written properly. They were. So if I copy and add new files to the Unraid disks they are all written okay and recoverable. It's just that the UNRAID drive replacement procedure and rebuilding the disks FAILED to work properly when I replaced the hard disks. This is a serious serious bug as far as I am concerned and I want to report it here in case anyone else has the same issue. I have no idea how many other files might also be corrupted during the rebuild process. So far I've noticed all my .pdf documents won't open. I've tried playing some of my many video mp4 files and they seem to be intact and play. I am concerned about other files types that might surprise me one day when I try to use them now... too many to list like (.exe, .doc, etc.). Anyone else have this problem after replacing hard drives and letting Unraid rebuild them from Parity drive? Oh, No! I just tried checking some .zip and .exe files and they too are all corrupt! BAD! Oddly enough, I can open .txt and .docx documents.