mnever33

My log is full of these: upnphttp.c:1061: warn: HTTP Connection closed unexpectedly Any idea what it means?

Hi. I just found out that this docker is spinning one of my disks. It keeps opening files from Disk5 for no reason. I have not added any new media files in /mnt/user (/media path) and none of the existing files is used by any dlna client... So why minidlna keeps scanning this disk? Thank you...

Thank you. Running extended on 5 now... May I ask why Disk6 should be replaced? Also what about disks 2 and 4 that have Reported Uncorrect and Reallocated sector ct errors? Nothing wrong about 2 and 4?

The extended test completed successfully for Disks 2 and 4 but for Disk 6: Errors occurred - Check SMART report Disk 6 also failed the short test. Now I see 50 errors on unraid's Main page for Disk 6 and 5! (Disk 5 passed the short test though. I'm running extended test now...) Please help... tower-smart-20200514-0929_Disk6.zip tower-smart-20200514-0200_Disk2.zip tower-smart-20200513-2003_Disk4.zip

I' m running the extended tests on these three disks and I' ll post the results. Thanks again.

Hi. I recently received notification about Read Error on Disk4. I checked the system log and I see Read Errors on Disk6. Also Disk2 has Reported uncorrect value of 6. None has Pending Sectors though... Can you please advise? Does any of these disks need replacement? I attach the diagnostics zip. Thank you very much! tower-diagnostics-20200513-1238.zip

The solution is to enter eth0 at Network Type. Only then the Fixed IP address field will show (I'm on 6.4.1)... Now the only problem is the graphs not updating.

Hello. When I try to install the container I'm getting this error: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='pihole' --net='bridge' -e TZ="Europe/Athens" -e HOST_OS="unRAID" -e 'ServerIP'='192.168.1.11' -e 'DNS1'='8.8.8.8' -e 'DNS2'='8.8.4.4' -e 'IPv6'='False' -e 'TZ'='Europe/Athens' -e 'WEBPASSWORD'='admin' -e 'INTERFACE'='br0' -e 'DNSMASQ_LISTENING'='all' -p '53:53/tcp' -p '53:53/udp' -p '80:80/tcp' -v '/mnt/user/appdata/pihole/pihole/':'/etc/pihole/':'rw' -v '/mnt/user/appdata/pihole/dnsmasq.d/':'/etc/dnsmasq.d/':'rw' --cap-add=NET_ADMIN 'diginc/pi-hole:latest' a6d1eed028308cf1bee761c286d6a07fc6d2fad4e27661e3a7cbc1d5fd3420fa /usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint pihole (8771ee95e57f0209e3a1cb452d96767d776904d74ac9baa17817755812973ec1): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use. The command failed. Can you help?

Active Streams only work for SMB? Not NFS?

Hello. In my Main screen of unRAID I see that there are some reads/writes in 2 of my data disks in the array. I installed this plugin but it doesn't show why these disks are spun up. File Activity is clear. There souldn't be any activity in any of the disks of my server at the moment. So why are the Reads/Writes values changing in the Main screen, keeping these two disks from spinning down? Is unRAID doing any reads/writes randomly for some reason? Thank you.

Thank you so much for your help. That disk is still under the warranty so I will return it asap...

Thank you. Extended SMART test always fails after a few seconds. The short one is OK (no errors). I changed SATA cables but that's not what is causing the problem... tower-diagnostics-20180202-0953.zip

Thanks for your help. Unfortunately, the extended SMART test did not pass: Last SMART test result: Errors occured - Check SMART report In the SMART report the last entry changed to this: 200 Multi zone error rate 0x0008 200 200 000 Old age Offline Never 50 Does that mean that my drive is failing? Should I swap the disk cables anyway? Just to make sure that it's a drive problem... Because if it's a controller problem then I would change the motherboard (replace it with one that has 8 SATA ports)... Please help identify the problem.

Hello. I got a red X in one of my data drives. I checked the SMART report for that drive (sdg) and I didn't see anything wrong. So I decided to re-enable the drive and rebuild it. But the rebuild process failed (twice), giving me a lot of write errors. I don't think that there is a problem with this drive. Is it maybe the controller? Can you please help? I attach the diagnostics file that I downloaded before I start the rebuild and the syslog file that I downloaded after the failed rebuild attempt(s)... Thank you. tower-diagnostics-20180201-1758.zip syslog.txt

I've modified the XFS conversion post (found here), and added warnings to it, marked in blue. I'm afraid it never occurred to me that anyone would be modifying the original drive during the conversion, but it's probably a relatively common occurrence. I often do things differently than most people, and need feedback like yours to correct me. Please review what I've written, and tell me if it could be improved, and any other suggestions you may have. Thank you. I have only two Docker apps installed: Transmission and PlexMediaServer. No VMs, Plugins, or Mover... I repeated all the steps (until 9) in your guide, but this time I stopped these apps before step 1! The copy in step 8 completed successfully, as expected. But the verification in step 9 took much less time to complete than step 8 (which is strange) and came up with many messages such as this: skipping non-regular file "appdata/PlexMediaServer/Library/....." However, I compared the contents of the two disks and they are identical! To make the comparison, I used the commands dir \\tower\disk10 /s and dir \\tower\disk11 /s from my windows PC, as suggested. Fortunately, the output of the dir commands shows the same number of files, folders and bytes for disks 10 and 11, so I guess everything is OK. In unRAID's Main page I see that in XFS disk11 (4TB) uses 1.69TB (2.31TB free) and in ReiserFS disk10 (also 4TB) uses 1.67TB (2.33TB free). That means that for the same amount of data, XFS needs slightly more space than ReiserFS. Is this normal? I am now moving on to the next steps with a little variation. I see that in your guide you always keep disk11 empty, in order to receive the data from the other drives. I find that all the assign, unassign, missing drives, unmountable, etc a little confusing for me to follow... So what I want to do is follow bjp999's guide on the first page, but instead of creating a "t" directory on the destination disk (as he suggests) I will exclude it in Global Share Settings (as you suggest), in order to avoid duplicates in shares... In summary, now that disk11 (XFS) has all the contents of disk10 (ReiserFS), I will exclude disk10 in Global Share Settings and then format it in XFS. Next I will copy the contents of disk9 to disk10. Then exclude disk9, format it, copy from disk8 and so on... I hope I understand it correctly...

Thanks again! I believe that instructions should point out that all docker apps must be stopped before rsync copy. Otherwise the verification (in step 9) will fail. So if I understand you correctly, should I let the rebuild process finish and THEN format the new drive (that I bought to convert all array to xfs, I didn't replace any disk) to xfs and then rerun the rsync commands?

The verification (rsync -rcvPX) found many differences between the files of the source disk and the destination disk. Source disk used 1.68TB but the destination disk used 1.69 Why? Is it because of the transmission (nothing was downloading, only uploading) and plex docker applications that are running? Most of these differences were from appdata/transmission/resume folder. Should we stop all docker apps before rsync? Now I messed things up! I changed the file system of the new disk that I bought to convert to xfs, thinking that I could reformat it (delete everything) and start over. But now it's doing a data rebuild. The new (destination) disk is now unmountable (and unformatted). Should I let data rebuild finish? And then? Please help..

After moving things around to other disks, if you have any user shares that are configured to include or exclude specific disk#s, you may have to change those settings to match where things have been moved. Alternatively, you could set a New Config and change the drive assignments so that the disk#s match the user share settings. If you only have single parity, changing the drive assignments will not invalidate parity, so you can check the box to tell it parity is valid. If you have dual parity, then parity2 will not be valid if you change the drive assignments. I don't know if it will allow you to rebuild only parity2 or if it will do both in that case. Thank you so much for your reply. I have one single parity disk and all my shares have no excluded disks (Included disks: All) So in my case, after converting all drives to xfs and the smallest data disk is empty, should I run New Config or should I just do nothing?

That guide does still work. However, I've made some improvements, and documented a complete step by step procedure here. I think once you've read and understood the details of how both procedures work, you can invent your own customized procedure. Please correct me if I'm wrong. As far as I can understand, the main difference between the first guide (from bjp999) and the last one (from RobJ) is this: - The first guide uses the cp command to make the copy and THEN the rsync -nrcv command to verify the integrity of the data. - The last guide uses only the rsync -avPX command (rsync -rcvPX is optional) I believe that the guide in the wiki (http://lime-technology.com/wiki/index.php/Upgrading_to_UnRAID_v6#Converting_Drives_from_ReiserFS_to_XFS) refers to the RobJ's guide but I cannot understand this part: When all drives are done, and the last Reiser drive re-formatted, you have a choice: Correct all of the drive includes and excludes for all shares, plus all other drive references Or use New Config to re-assign all drives back to their original drive number (marking parity as valid) If someone could explain this part... So which method should we follow because all these guides are a little confusing. Thank you.

As always.... soon™ My friend, this is your reply at my thread that I linked above: "Maybe it is something that needs to be fixed, but waiting for that fix it might be better for you to convert to XFS as a quicker solution. Problem is not everyone with a ReiserFS array has seen the issue but it's been sporadically noted since V6 has been released. Not sure anyone has ever pinned down the cause..." Do you now know if this issue is going to get fixed? Is there an update concerning this ReiserFS problem in v6? Really hoping that the cause of the problem will be pinned down and solved when stable v6.2.0 is released!..

Many users with ReiserFS are facing this problem (unraid freezes randomly when accessed from the network). The current solution is to convert to XFS but for many of us this is not an option. http://lime-technology.com/forum/index.php?topic=50304.0 So if the new version of unRAID solves this issue (server becomes totally unresponsive, especially when making a write from a network location), that would be great! I'm reading the changelog of beta23 but I cannot figure out which entry refers to this problem. Could you please provide more information? Also, when is the stable version (6.2.0) going to be available? Thank you

Thank you all for your replies. After further reading I see that this is a common problem for those that use the ReiserFS. I have hard rebooted my server too many times this week.. It is working fine at first boot but after some time the system freezes, when I access it from my home network in order to make a write. It becomes totally unresponsive! Unfortunately converting to XFS is not an option for me. All my disks are about 80% full and I do not have the necessary space to move my data around. Also, I cannot add a new HDD because I have to pay for the Pro license (now I have 1 parity and 5 data drives, no cache). The only solution is to go back to v5, which was rock solid since 2009 that I use unRAID! Thank God I have kept the contents of the flash drive before I format it for v6. So I will just re-format it and copy v5 again... That's sad because v6 is so much better than v5 but there is no other alternative for me. In the future, when I add a new large HDD I will be able to format all the drives to XFS...

But that doesn't make sense because unRAID 6 should be stable with both file systems. If there's not problem with the hardware of my server, then this is something that needs to be fixed. Hopefully someone can look into my diagnostics file and help me narrow down these freezes...

Is there anything out of order in my diagnostics?

Complete diagnostics zip. Thank you... tower-diagnostics-20160711-2258.zip