Leaderboard

Application Name: LazyLibrarian Application Site: https://github.com/DobyTang/LazyLibrarian Docker: https://hub.docker.com/r/linuxserver/lazylibrarian/ Github: https://github.com/linuxserver/docker-lazylibrarian/ Please post any questions/issues relating to this docker you have in this thread. If you are not using Unraid (and you should be!) then please do not post here, instead head to linuxserver.io to see how to get support.

How to setup Dockers to have own IP address without sharing the host IP address: This is only valid in unRAID 6.3 series going forward. 6.4.0 has this built into the GUI but currently have a limitation of needing extra IP addresses for each of your interfaces and needs to delete all manually created docker networks. If you don't like that, you can opt to create the network manually like here and disable the docker network auto cleanup. 6.4.1 is now more intelligent about this and presents a relatively powerful UI that covers most simple cases. You don't need to assign unnecessary IP address to additional interfaces anymore. refer to https://lime-technology.com/forums/topic/62107-network-isolation-in-unraid-64/ for more details Single NIC only: Some assumptions: We'll be using a shared interface br0 (This allows us to use the same nic with virtual machines, otherwise its alright to use eth0) The IP address details are: unRAID = 192.168.1.2 Gateway/router = 192.168.1.1 Subnet = 192.168.1.0/24 Docker IP pool = 192.168.1.128/25 (192.168.1.128-254) A new docker network will be established called homenet Login via SSH and execute this: # docker network create \ -o parent=br0 \ --driver macvlan \ --subnet 192.168.1.0/24 \ --ip-range 192.168.1.128/25 \ --gateway 192.168.1.1 \ homenet Modify any Docker via the WebUI in Advanced mode Set Network to None Remove any port mappings Fill in the Extra Parameters with: --network homenet Apply and start the docker The docker is assigned an IP from the pool 192.168.1.128 - 192.168.1.254; typically the first docker gets the first IP address # docker inspect container | grep IPAddress "SecondaryIPAddresses": null, "IPAddress": "", "IPAddress": "192.168.1.128", # docker exec container ping www.google.com PING www.google.com (122.2.129.167): 56 data bytes 64 bytes from 122.2.129.167: seq=0 ttl=57 time=36.842 ms 64 bytes from 122.2.129.167: seq=1 ttl=57 time=36.496 ms ^C # docker exec container ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes ^C # At this point, your gateway/router will have a first class network citizen with the specified IP address An additional Extra Parameter can be specified to fix the IP address: --ip 192.168.1.128 The container will not be allowed to talk to unRAID host due to the underlying security implementation with the macvlan driver used by Docker. This is by design That's it. Secondary NIC is available: Some assumptions: We'll be using a dedicated interface br1 (the native eth1 interface can used here too) There is no IP address assigned to the interface The IP address details are: Gateway/router = 10.0.3.1 Subnet = 10.0.3.0/24 Docker IP pool = 10.0.3.128/25 (10.0.3.128-254) A new docker network will be established called docker1 unRAID has an ip of 10.0.3.2 Login via SSH and execute this: # docker network create \ -o parent=br1 \ --driver macvlan \ --subnet 10.0.3.0/24 \ --ip-range 10.0.3.128/25 \ --gateway 10.0.3.1 \ docker1 Modify any Docker via the WebUI in Advanced mode Set Network to None Remove any port mappings Fill in the Extra Parameters with: --network docker1 Apply and start the docker The docker is assigned an IP from the pool 10.0.3.128 - 10.0.3.254; typically the first docker gets the first IP address # docker inspect container | grep IPAddress "SecondaryIPAddresses": null, "IPAddress": "", "IPAddress": "10.0.3.128", # docker exec container ping www.google.com PING www.google.com (122.2.129.167): 56 data bytes 64 bytes from 122.2.129.167: seq=0 ttl=57 time=36.842 ms 64 bytes from 122.2.129.167: seq=1 ttl=57 time=36.496 ms ^C # docker exec container ping 10.0.3.2 PING 10.0.3.2 (10.0.3.2): 56 data bytes 64 bytes from 10.0.3.2: seq=0 ttl=64 time=0.102 ms 64 bytes from 10.0.3.2: seq=1 ttl=64 time=0.075 ms 64 bytes from 10.0.3.2: seq=2 ttl=64 time=0.065 ms 64 bytes from 10.0.3.2: seq=3 ttl=64 time=0.069 ms ^C --- 10.0.3.2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.065/0.077/0.102 ms At this point, your gateway/router will have a first class network citizen with the specified IP address An additional Extra Parameter can be specified to fix the IP address: --ip 10.0.3.128 The container can happily talk to unRAID as the packets go out via br1 and talk to the host on br0 That's it. Some caveats: With only a single NIC, and no VLAN support on your network, it is impossible for the host unRAID to talk to the containers and vice versa; the macvlan driver specifically prohibits this. This situation prevents a reverse proxy docker from proxying unRAID, but will work with all other containers on the new docker network. We can only have one network defined per gateway. So if you already have docker network br0 on your main LAN (gateway 192.168.1.1), docker will not allow you to create another network referencing the same gateway. I cannot confirm yet what happens in the case of two or more NICs bridged/bonded together (but it should be the same as a single NIC) unRAID 6.4.0 We need to disable the docker network auto generation and cleanup if we want these settings to remain (until the auto cleanup is made more intelligent). The code below should be inserted into the go file before /usr/local/sbin/emhttp is started. The code below will disable docker network auto creation too, so it will behave like 6.3.5. It seems that the docker page will happily show any docker network you have defined, so you can just use them as normal and no longer need to set Extra Parameters. Again not needed with 6.4.1 going forward. # stop docker network creation and pruning sed -i -e '/# cleanup/,+3s/^/## /;s/^ custom_networks/## custom_networks/' /etc/rc.d/rc.docker

I would love a progress bar/percentage thingy for mover

I will split his posts into General Support.

I'm pretty sure some people in the forums have bought the 2650 without issue. Not much difference between it and the 2670. I believe the stepping you would want is the SR0KQ. Have you checked out Natex? They still have some decent deals on mobo/chip/ram packages.

Just thought I would add a comment about this. Parity isn't particularly deep. It is much, much simpler than file compression and codecs, for example. From reading some comments on this forum, it seems some have the idea that the parity disk magically has a copy of all the other disks, like it has compressed them all down (even though many files on the disks are already compressed) to fit on a disk not nearly large enough. If you take a look at that wiki I linked, and take a little trouble to understand, everything about how unRAID works and operates makes a lot more sense. When you have a problem or just need to change something in the array, there are instructions for a lot of situations already in the wiki. You can get more instructions by asking on the forum, and I encourage everyone to do so. But if you understand parity, you will understand why those instructions work. So, you will better understand (and not misunderstand) the instructions and be less likely to make mistakes that make things worse. The reason some people can even write those instructions in the first place is because they understand parity.

if your talking at the raw read error rate and seek error rate then i agree:- http://sgros.blogspot.co.uk/2013/01/seagate-disk-smart-values.html in short your drive looks healthy to me.

EVGA founders edition but pretty sure it would work for any reference card.

change the tag back over to "latest"

That is not going to be an easy task if you want to run it in a docker container. You first need to get the nvidia drivers installed on unraid, which means you will have to recompile the kernel and package it all up again. Then get all the dependencies for the drivers installed. The best solution is to run a vm and pass through the GPU and install docker on the vm.

It would be interesting to see what % of the unRAID market need/want the additional features. While stability and security of my data is #1, if I couldnt add capabilities like I can now through docker (previously plugins), I probably would have moved to a new platform by now. VM's on the other hand, I have no need for at all. If LT had that info of what % of their clientbase want what, it would be interesting to map that against LT's combined development effort in those areas to see if it matches., No point putting 25% of Dev effort into VM integration of only 5-10% of the userbase use/want it.

What are people finding Xeon E5-2670 pairs for now? $163 is the lowest I see on eBay for 2.

I guess it is possible that with the phone as the hotspot, that a request from the Chromecast to the phone itself would be satisfied locally and not traverse the internet, and thus not incur data charges. There might also be a way to completely inhibit cellular traffic making this into a portable wireless router.

A few thoughts ... (a) Conceptually, it's not all that difficult to do. There's no problem writing low-level disk I/O routines in Windows ... I've written quite a few over the years, but NOT in the last decade (programming is decidedly a young person's "game" ... it's all too easy to spend 20-30 hours focused on a problem and forget about minor details like food & sleep). The pre-clear script is essentially a read test of the whole disk; writing zeroes to the entire disk; doing another read test along with some intensive seeks to exercise it a good bit; and writing a special "signature" on the disk that "tells" UnRAID that it's been pre-cleared. The only thing that isn't pretty straight-forward is the last bit ... and I assume Tom would provide the details of that to anyone who was writing a utility to do this (as he did for Joe many years ago). (b) Pragmatically, it's simply not needed. Pre-clear serves two fundamental purposes: (1) The original purpose was to eliminate the long down-time on an UnRAID array while a new disk was being cleared. The array was unusable for the duration of this, so adding a new disk was a bit of a PITA. Joe L. wrote the pre-clear script to provide a way to have a disk "pre-cleared", so it could be instantly added to an array ... UnRAID would recognize the special signature; write zeroes over that signature; and "knew" that the rest of the drive was already zeroes, so there was NO impact on parity, so the drive could simply be added to the array. and (2) As part of the process, Joe included some rudimentary testing -- the pre-read and post-read phases along with a fair amount of random seeks. This 2nd part has become a de-factor way to "test" a new disk before incorporating it into the array. Why isn't it really needed? r.e. #1 => UnRAID no longer makes the array unavailable while clearing new disks. It simply clears them; THEN adds them to the array; and the array is never unavailable for the user during this process. So the primary initial motivation for pre-clearing drives is no longer a factor. r.e. #2 => It's certainly a good idea to test a new disk before using it. But the manufacturer's free testing utilities do a very good job of this. WD's Data Lifeguard; Seagate's SeaTools; HGST's Drive Fitness Test; and several 3rd party tools are all good ways to test new drives -- and do every bit as much of a test as the pre-read and post-read phases of pre-clear. These all can run on a Windows box with no problem. Personally, I test new drives with WD's Data Lifeguard => I run the Quick Test; then the Extended Test; then I Write Zeroes to the entire drive; and then I repeat the Quick and Extended tests. I've found a few "infant mortality" issues over the years with this regimen; but I've NEVER had a drive that passed this regimen cause any problems during it's first few years of life. If I was going to add the drive to UnRAID as a new drive (not as a replacement, where clearing it makes no difference), I would then connect it to a spare PC; boot a USB flash I have configured with the free version of v5 and the pre-clear script; and run one pass of pre-clear with the -n option, which will skip the pre- and post- read phases => i.e. just do the clear and mark it with the pre-cleared signature. This takes about 1/4th as long as a normal pre-clear cycle. However, with v6.2 this is no longer necessary, since UnRAID will clear it without any impact on the array operations.