NAS

Only partition is exported. You can extract the disk device using the following code: DISK=$(echo $DEVICE | grep -Po "/dev/sd[a-z]$") Appreciated as always.

Having a brain fart. I have a umount script that Unassigned Devices calls and does a bunch of things like index etc and its great. Totally rely on it for my workflow so a big thanks. However I just went to add a simple `smartctl -a /dev/sds > blah.txt` to it but it seems the partition device is set as a variable i.e. /dev/sds1 but the disk device partition device, e.g /dev/sda is not. Before I go away an pull together a kludge and I missing something obvious?

So this doesnt get lost: http://lime-technology.com/forum/index.php?topic=49221.0

My personal opinion only in this very strange situation. I can only see the licenses of the upstream dependencies and not the license zap2xml is distributed under. This is the root of the misunderstanding that I myself would easily have made. Anyone can be forgiven for missing "not for redistribution" hidden among 2467 other words. Saying that the situation has been clarified now and the docker as it is today should be removed immediately. The proposed solution that writes a guide and a container that need the user to complete seems viable under the terms of redistribution but not within the current terms of the license and copyright. Depending on your location no license means a large variety of things from "fair use for satire only" and "public domain" all the way to "not licensed". Equally the statement of "personal use" is unclear as it specifically omits the "non commercial clause" that stops any corporate installation i.e. "personal" does not mean sole. The spirit however is clear that "personal" should mean sole use which in turn means no family usage (which is odd). My opinion is the author is obviously 100% right and until the license is clarified any work done to make it easier to install using docker could be negated. Find an alternative.

Thats great thanks. I can see subsonic on the list with a low vote count so I cant see madsonic being voted on much. Will wait and see as I dont think it is fair for me to vote just because I want a base OS change when other people are voting for things that dont exist at all. ta

I am in the process of checking out all my containers to see which ones are still maintained and low and behold almost every container I need in production is covered by LinuxServer.io. Kudos. I am not sure if this is the correct place to make a request or if it is even proper but if it is the I humbly request Madsonic be considered http://www.madsonic.org/ Two containers exist already, the original one by binhex (well maintained but is arch based) and alternate by gfjardim ( Phusion based but not maintained).

For what it is worth I too would use iSCSI now

Same problem here out of the blue they blacklisted my whole mail server and wanted a silly amount of personal info about me to unblock the server. I just no longer allow people to send mail to M$.

Sounds like its not a sources.xml issue then. Pity it reeked of one. This is perhaps OT now but I also path sub favourites. One other funky thing i do is copy the textures dbase from the central source before I start each client. This is a kludge but reduces the re downloading of artwork per client to next to nil and consequently makes it pretty safe to path sub artwork again.

This sounds like a sources.xml mismatch to me. FYI I path sub these and a couple of other configs as well. Perhaps we should work path substitution into the container and recommend that all users use it.

I am in two minds...... even ESX (the big driver for iSCSI over the last few years) is migrating to nfs. Saying that the use cases that remain are from the kind of people (like yourself) we want to actively attract to the community. Advanced show case use cases also help sell the product via the "cool factor", reviews and personal recommendations. I would use it so if it isnt a huge effort it gets my vote.

That sounds fixable in unRAID to me. There should be no real reason why unRAID should stall like this (conceptually at least).

I dont really care either way but I have to say all the plus cases for it so far feel to me like work arounds for client problems and spinning up wide arrays feels like one of things i hated about old fashioned RAID. I hold out judgement because I dont believe we have any info why it is being removed other than it is perceived its not being used. That is never going to be the case as in any large userbase there will always be people using every feature in some way.

I would also be curious how many of these use cases could be better handled with data disk balancing and some upstream bug reports to software vendors

That seems to be a common theme.

With the size of drives now it makes far more sense to ballance the data itself now rather than waste disk spin ups

I personally actually think perl and python which are large packages should probably not be in the nerd pack which should be kept slim. Perhaps they should each be in a pack of their own? Perhaps one pack for new nerdy stuff thats never been native and another that adds back in stuff that used to be included. TBH I am easy.

Could consideration be given to Perl since it was dropped from unRAID proper this seems like the natural place for it now alongside python.

Sounds like a plan then. I think we should take this to github, create a stable branch based on current XML spec then an unstable based on the new spec. I dont know who owns the layout copyright but perhaps they could be asked to make it GPL and pass it into this new project.

Thats a very fair point and anything XML related is always just that bit harder (as in bloody hard) to automate on the command line. I wonder if we could write a version converter. (I pretty much hate XML the amount of time ive wasted trying to manipulate stuff is scary) Content wise though the new description field is exactly the kind of thing normal every day users could do pull requests for which opens the door for a whole new level of contributors which i like.

Sorry I missed your reply. Essentially just a description field so that devs can explain what each and every element is for. If you look at some of the current global descriptions they often have per field descriptions bundled together as it t stands. Its i inconsistent and ugly and for the target audience of "non technical app consumers" its not idea. Also perhaps most theis schema to github to track chnages?

http://ark.intel.com/products/42770/Intel-Celeron-Processor-E3200-1M-Cache-2_40-GHz-800-MHz-FSB It is indeed 64bit

I absolutely agree. Unfortunately this is not a problem of our making but as you say its one we have to deal with. Essnetially you have to teach users a bit of docker technology for them to set this up right. The way docker is being "sold" now in unRAID land is a point and click application store and in many ways it is.. unfortunately this problem breaks that model completely. I suspect LT have some thoughts here.

I am late to this party but we absolutely should not be advocating a default of passing /mnt/user RW into all docker running as root. Yes it is easier for the end user but one day it will cause someone to lose all their data, that is an absolute certainty (russian roulette with hardly any bulltets but with thousands of users and random strangers loading the gun = bad). Even if no one ever makes a mistake there are plenty of applications out there that collect info on people. Why on earth would we let all apps see people documents and family photos. Docker hub is the wild west and they intentionally have a very low skill barrier to post there. At the very minimum and ONLY if we must dumb this down to "share everything with everything" it should be RO but I vote as strongly as I can not to do this as it is essentially the mistake all the phone OS's made and look how much that ruined things.

Perhaps even the default?