vinnybhaskar

Yep, it does work with the disk being referenced instead of the user share. However, I was wondering what prevents the user share from working when either of them should suffice.

Any specific reasons why this Docker images needs /mnt/cache/appdata instead of /mnt/user/appdata? A lot of other Docker images I use (even from LSIO) works well with /mnt/user/appdata. OK, should have been fixed in V6.2.4 of unraid. As an aside, you'll get much better performance from your docker containers if you can put the appdata on a cache disk. I don't see any mention of any fix in unRAID 6.2.4 for the above issue. Could you please explain?

Well, I forgot to mention that I had seen that post and I do not need VM running. The Atom boards any how do not support virtualization.

Hi everyone, I need a cheap SATA controller to add more ports to my low power NAS built around the Intel Atom processor. Currently, I have an onboard Marvell 88SE9230 controller which keeps dropping disks under heavy load. I have found two cards which are based on the Marvell 88SE9215 and the ASM1061 controllers. The Marvell card has 4 Ports and the ASM1061 has 2. I'm inclined towards buying the 4 Port Marvell, but afraid due to the ongoing issues with the onboard 9230 controller. What's your experience with these cards? Which is more reliable? Are there any other cards around the same price with a different controller? Marvell 9215 card: https://www.amazon.com/IO-Crest-Controller-Non-Raid-SI-PEX40064/dp/B00AZ9T3OU/ref=sr_1_3?ie=UTF8&qid=1482424123&sr=8-3&keywords=Sata+controller ASM1061 card: https://www.amazon.com/IO-Crest-Port-PCI-Express-SY-PEX40039/dp/B005B0A6ZS/ref=sr_1_5?ie=UTF8&qid=1482424123&sr=8-5&keywords=Sata+controller

Finally, got the issue resolved by adding IP route inside of the container. In all my attempts earlier I was using the wrong gateway. Here's the correct route: ip route add 192.168.1.0/24 via 172.17.0.1 Dev eth0 The IP after "via" is the gateway and that needs to be the container gateway. Docker sets this automatically when creating a virtual Ethernet bridge.

Thanks for the reply. Well, I forgot to add this. I'm using a custom docker image I created. Additionally, it's an OpenVPN client connecting to a VPN server.

I've been struggling with OpenVPN routing for last couple of days. Hopefully someone can help me get this sorted. I have a Docker container with network set to bridge. At first, I'm able to reach this container from my local network (192.168.1.0/24). But, the moment I start OpenVPN and initiate a VPN connection the container is no longer reachable from the local network. However, the container remains accessible from the host unRAID OS. Which is what's confusing me. Before initiating the VPN connection the IP route inside of the container appears as following: bash-4.3# ip route default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2 Once the VPN gets connected, OpenVPN modifies the IP routes to: bash-4.3# ip route 0.0.0.0/1 via 10.108.21.1 dev tun0 default via 172.17.0.1 dev eth0 10.108.21.0/24 dev tun0 proto kernel scope link src 10.108.21.40 128.0.0.0/1 via 10.108.21.1 dev tun0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2 178.255.153.76 via 172.17.0.1 dev eth0 What routes should I be adding to allow any computer on my local network to communicate with the Docker container while the VPN is active? Or is there something else breaking this? Using UnRAID 6.2 RC4

I did not get the chance to read this thread in it's entirety. Please ignore if this bug has already been reported. With RC4 "make_bootable_mac" script is rendering the flash drive un-bootable and corrupts the contents of the same. See the attached screenshots. The RC4 version of the script encounters an error and doesn't seem to complete all steps in comparison to the RC3 version. Also attached is the screenshot of the disk initialization error. This happens when re-inserting the flash drive on the Mac after the script has completed and ejected the flash. The issue appears to be because of a typo in the device identifier hdutil is trying to unmount. Should be "/dev/disk1s1" instead of "/dev/disk1s1s1".

That makes perfect sense. I went ahead and pre-cleared the disks once and they came out good! Thanks!

Reallocated sector count and Current pending sector are zero. Do I need to look at any other attributes as well? The disks were in use on a Mac and were almost full.

I have examined their SMART attributes and find no issues. These disks have had data written to and read from them frequently. They were daily drivers. So I believe it would be safe to assume they are good drives. Secondly, even if I were to run 1 or 2 pass of pre-clear, that would not necessarily mean they would not fail on the third. I think pre-clearing for stress testing makes sense with new disks to rule out any DOAs (infant mortality).

I’ve read a lot on pre-clearing disks prior to adding them to an array. I understand pre-clear does the following: 1. Clears the disks so that unRAID does not need to do the same 2. Stress tests disks to rule out bad disks Let’s park the idea of stress testing the disk. The disks I’m concerned about have been in service for a while and I know they are good. Coming back to clearing the disk. I believe this is only needed when adding disks to an existing array with a valid parity. Emphasis on "existing array with a valid parity". If I were to start a NEW array without a parity disk, unRAID just needs to format the data disks to one of the supported file systems and bring the array of online. I can then stop the array and add a parity drive which would trigger and parity build. Using the above process I can completely skip the clearing/pre-clearing process for NEW arrays. Am I correct?

I was reading the post "Will server Power button gracefully shut down the server?" (http://lime-technology.com/forum/index.php?topic=6078) And was wondering whether it applies to 6.1.x or 6.2. Do these new versions support graceful shutdown (stopping the array and then shutting down the server) out of the box on press of the power button? I wasn't able to try out the procedure listed out in the post above since the command "cat /proc/acpi/event" errored (if that's a word) out. What's the correct path in case of 6.1.x or 6.2? Additionally, during a power outage when the UPS triggers UnRAID to shutdown, what happens to processes such Parity check, Parity re-build, Preclear, etc. Do these processes gracefully stop prior to the shutdown? Is there any process that can cause data corruption or other unwarranted issues when such a shutdown occurs?

That's a good point. I should try that too. Would certainly make things simpler if disastor strikes. Thanks for your help guys. Loving the support here at unRAID forum!

Would it be the "Zero only the MBR" option? See attached screenshot. Removing and preclearing an existing array member will void parity, so if you do that you will need to rebuild parity. Preclearing is not necessary to format a disk in unraid. Makes sense when you want to preserve the parity. However, in my case I'm going destructive since it's just an experiment. BTW, would your initial answer be valid even when starting out with a new install of unRAID on flash?

1st, parity doesn't ever have a format, so no need to do anything to a disk that you want to use for parity besides assign it to the parity slot when you do a new config. 2nd, there is no need to do a new config (and build parity all over again) if all you want to do is format the data disks. When the array is stopped, you can click on the disk you want to change in the main GUI, and change the file system type to a different format. Start the array, select the option to format the disk, allow it to finish, stop the array, go back to the same disk setting, and select the file system type you want back again. This time when you start the array and format the disk, you can just start using it right away. Parity stays valid during this whole procedure. Quick recap. Change disk format to something else, format disk, change back to format you want, format disk again, use newly empty disk. Cache works the same way, just need to stop the array before making changes to desired file system type. Ah! I see. Though I had come across this option in my searches, apparently it did not feel intuitive. Would this apply even when starting out with a new install of unRAID on flash? Any way to do this using the preclear GUI plugin by gfjardim?

I'm currently messing around with unRAID to fully understand it's operational aspects and in the process breaking things. I'm preclearing disks every time I want to start with a new config while discarding any data on the disks. However, preclearing takes a while. Is there a quick way to format cache, data and parity disk to start all over quickly?

That's good to know. Thanks!

Hello, I just started out on my first unRAID build. I have an Intel Atom based motherboard with a Marvell 88SE9230 SATA controller onboard. Post booting into unRAID 6.1.9, I see the following error in the Syslog: Jun 24 22:08:06 Tower kernel: ata12.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Digging deeper into the log I find "ata12" corresponds to the Marvell Virtual ATAPI device/controller: Jun 24 22:08:06 Tower kernel: ata12: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Jun 24 22:08:06 Tower kernel: ata12.00: ATAPI: MARVELL VIRTUALL, , 1.09, max UDMA/66 Jun 24 22:08:06 Tower kernel: ata12.00: configured for UDMA/66 Searching further, I came across this bug (https://bugzilla.kernel.org/show_bug.cgi?id=98171) affecting the Marvell SE91xx SATA 3 controllers in Linux kernel version 3.15 and above. I believe the same bug is affecting the Marvell 88SE9230 SATA controller as well. Until now I have not had any issues with the build for past 48 hrs. I have been mostly tinkering with unRAID to understand it better and I have also precleared two small drives (250GB and 80GB, two pass each) to test smooth operation. Do I need to be worried about the error? Is there something I can do to fix it? BTW, I have swapped SATA cables and power connectors as per recommendations in few posts. Additionallly, I disconnected the drives completely, but the error remains. PFA the syslog. tower-syslog-20160624-2210.zip