Mickey

There seem to be a lot of posts here that point to the OS as the issue. Clearly, this is not the issue as the fix lies in how unRaid assigns the subsequent share device to the bus because, I believe, the script assumes a bus address, rather than testing for free resources and assigning bus according to same. This, IMHO, results in a reassignment of resources in the OS - since it had already assigned the prior resource to enp1s0 (or whatever network int id it had previously assigned, it's forced to assign a new resource id to the new interface.) - it's a failure of the Limetech folks to properly test their scripts.

This is likely because of a bus conflict created by the script that creates the VM XML file. Check your VM { VMs tab, right-click on the VM you are having an issue with, then click "edit" }. Click on "XML view" (top right, just below banner). Look in the XML file for both the <filesystem ..........................> and the <interface ......... > labeels. Compare the <address ....... bus='0x02' > in both to see if they are the same. If they are ( I found this to be my issue when creating shares ), then change the bus address on your share to another, unused address (I ended up using bus='0x06' ). Not sure that this is the "correct" or "approved" fix, but it worked for me. - Mickey

I can "officially" confirm this issue. Adding a share, did indeed foul the network interface on my Ubuntu 16 (Running MS SQL). I dropped the shares and BAM, the system locates, and successfully brings the service back up. Funny thing though, adding the shares on my other Ubuntu VM didn't seem to interfere with raising the network or finding the interfaces. Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-130-generic x86_64)