I have an Ubuntu server VM that I want to mount a share into.  VM config -> advanced-> unRAID share (add path) -> unRAID mount tag (add tag) -> start server -> fails to start network service at boot recommends running systemctl status networking.service, screen shots below.  It sees the interface but won't start the service.  However if I remove the share it works fine. 

Hmm, very odd.  We don't have much experience using the virtfs method with Ubuntu VMs.  Our primary use-case for it in unRAID was for the Open/LibreELEC VMs config data mappings.  Those seem to work fine.  I would probably suggest posting in the Ubuntu forums to see if this is related to a kernel config parameter or something else amiss, as I doubt it is a host configuration issue.

For anyone wondering, it appears to work fine in Debian.  Probably just an Ubuntu issue, I was running Ubuntu 16.04.2 server, might have been fixed in a newer version but I'm just going to switch to Debian since it's pretty much the same.  Thanks for ruling out an unRaid issue Jon.  

I just stumbled across this post while looking to see where the UNRAID share is mounted within the VM

 

I was having the same issue with 17.04 

 

The following fixed this issue for me 

 

https://stackoverflow.com/questions/41609676/failed-to-start-raise-network-interfaces

 

ip link
example: lo , enp0s8

add following lines in /etc/network/interfaces

auto enp0s8
iface enp0s8 inet dhcp

restart your VM.

 

Hey guys, 

 

I had this same issue tonight when building an Ubuntu 16.04.01 Server VM. OS is installed fine and all seems well until I added my Unraid shares and rebooted. Suddenly, no network. Was seeing "Device not found" messages when trying to start the networking service. I did some digging and noticed that my nic used to be labeled enp2s2. After the shares were added and rebooted, I ran ip link only to find my nic is now labled enp2s6. After looking at the XML, I think it makes sense why. Below is a bit of the XML for this VM, AFTER I added the shares. Seems like the shares take precedence in the config file somehow and push the nic down to another slot. slot='0x06' in the config file apparently corresponds to enp2s6 nic label. To solve the problem, I was able to change the nic label in the /etc/network/interfaces config file and reboot. All is well again. 

 

Hopefully, that makes sense and it helps someone else. 

 

 <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/media/Movies/'/>
      <target dir='Movies'/>
      <alias name='fs0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    </filesystem>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/media/TV/'/>
      <target dir='TV'/>
      <alias name='fs1'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/>
    </filesystem>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/media/Kid Movies/'/>
      <target dir='KidMovies'/>
      <alias name='fs2'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/>
    </filesystem>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/media/Kid TV/'/>
      <target dir='KidTV'/>
      <alias name='fs3'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
    </filesystem>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/media/Music/'/>
      <target dir='Music'/>
      <alias name='fs4'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='52:54:00:c7:28:ff'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x06' function='0x0'/>
    </interface>

 

@alowishes, Thanks for your link. That is definitely part of the solution.

@ccmpbll, You are on to something. Adding an unraid share changes the ip link and thus necessitates editing /etc/network/interfaces to restore network functionality.  However, the unraid share is still not mounted to the VM for me on Ubuntu 17.04. Does it work for you? 

 

I can't get this to work by editing the VM XML. Instead, I edited /etc/fstab in the VM to mount the UR share to /media/unraid

Edited September 30, 20178 yr by kamhighway

Hi all, 

 

Just wanted to provide an update that fixed my issue, I ditched debian and went back to ubuntu, instead of doing the mount through the VM configuration I just mounted the network share via IP address in the etc/fstab.  It's been running great for a few months now.  If you do decide to do it this was make sure you pass the read/write privileges when mounting it in fstab.  I attached a picture of my configuration.  For reference my unraid box has 2 nics one onboard 1GBE connection (192.168.1.xxx) and one 10GBE twinax connection directly to another computer (10.0.0.x).  So essentially with this config my ubuntu VM is going externally looking for (10.0.0.x) 10GBE fiber card in the unraid box and accessing the data that way.  I haven't seen any performance issues with it yet.  

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)
 

Edited July 15, 20187 yr by Mickey

This happens on the latest version of Ubuntu as well. (version 18)

I can confirm. Hit the same issue... Quite annoying.

 

unraid 6.6.5.

Edited November 10, 20187 yr by ezhik

I had to re-create the VM with shares configured from the start. No issues so far.

 

I should probably write a guide about how to accomplish this properly...

same issue ubtunu 18.04

by running:

sudo dhclient enp3s0 

 

I was able to get a connection again

 

 

(first post here, so please yell at me if I do anything wrong)

 

Unfortunately the various suggestions such as setting up a mount in /etc/fstab were not working for me, as I'm trying to develop software inside this VM, and NFS doesn't play well with various build tools, due to no support for kernel functionality called "inotify" (Facebook's watchman package depends on it).

 

I haven't 100% confirmed any of this, but I think I know what's happening? I at least have a basic understanding of my case?

 

It looks like a brand new Ubuntu 18.04 installation is no longer using /etc/network/interfaces for network config, and is instead using /etc/netplan/50-cloud-init.yaml (I don't know if it's always the same filename).

 

I assume that this is related to the cloud-init stuff that was added to Ubuntu in the recent past, based on the name of the file.

 

For some reason, this is configured correctly before mounting a share. After mounting a share, I found that /etc/netplan/50-cloud-init.yaml had the wrong network interface identifier.

 

I don't know if my network interface identifier changed, or if the contents of this file changed.

 

My network interface is now called enp3s0 so I edited the contents of the file to look like this:

network:
    ethernets:
        enp3s0:
            dhcp4: true
    version: 2

(read more about netplan config at https://netplan.io/examples)

 

And the problem is solved. I believe that the other suggestions in this thread are workarounds, and this technically could be too, since I haven't confirmed which bit changes after mounting the share, or why it happens.

 

If I find more, I will post back!

 

(side note: If Unraid supported EZ VM snapshots, it would be a lot easier to figure this out. As-is, I have to reinstall Ubuntu over and over...)

Edited January 2, 20197 yr by SethTheGreat
Forgot to include link to netplan docs

 

 

 

 

3

On 8/30/2017 at 10:21 PM, ccmpbll said:

 

 

On 8/30/2017 at 10:21 PM, ccmpbll said:

Hey guys, 

 

I had this same issue tonight when building an Ubuntu 16.04.01 Server VM. OS is installed fine and all seems well until I added my Unraid shares and rebooted. Suddenly, no network. Was seeing "Device not found" messages when trying to start the networking service. I did some digging and noticed that my nic used to be labeled enp2s2. After the shares were added and rebooted, I ran ip link only to find my nic is now labled enp2s6. After looking at the XML, I think it makes sense why. Below is a bit of the XML for this VM, AFTER I added the shares. Seems like the shares take precedence in the config file somehow and push the nic down to another slot. slot='0x06' in the config file apparently corresponds to enp2s6 nic label. To solve the problem, I was able to change the nic label in the /etc/network/interfaces config file and reboot. All is well again. 

 

Thanks man! this helped me a lot

Edited June 5, 20197 yr by jebo87
weird formatting

I just had a hell of a time getting the network interface working again after adding a mount tag in the tower/VMs page.  (Btw this seems like an Unraid bug, hopefully it gets fixed eventually)

 

I'm running an Ubuntu 19.04 VM

 

When you add a mount tag, my Ubuntu VM's network interface logical name gets changed to enp3s0 (I don't know what it was before, but the problem is it has changed and now my netplan config needs to be fixed)

 

A temporary fix to get the VM back on the network like @snailbrain mentioned: 

sudo dhclient enp3s0

 

I had to edit /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg to setup static addressing instead of DHCP 

network:

  version: 2

  ethernets:

    enp3s0:

      addresses: [192.168.88.25/24]

- https://netplan.io/examples

- https://askubuntu.com/questions/1036266/what-is-the-most-authoritative-file-process-for-managing-ip-addresses-on-an-18-0

 

I ran some commands I found on various stackexchange threads

sudo cloud-init clean --logs

sudo cloud-init init --local

sudo netplan apply

- https://askubuntu.com/questions/1104285/how-do-i-reload-network-configuration-with-cloud-init

- https://askubuntu.com/questions/1029531/how-to-setup-a-static-ip-on-ubuntu-server-18-04

- https://askubuntu.com/questions/1036266/what-is-the-most-authoritative-file-process-for-managing-ip-addresses-on-an-18-0

 

Now my networking interface config persists between reboots

I have this problem in my freshly installed Ubuntu 20.04 VM. When I boot without any Unraid Share, i have network access, but no network when booting with a share.
 

ip link

gives me precisely the same output with or without share in vm-settings (after boot)

my link is called 'enp2s0'

'sudo dhclient enp2s0' seems to run forever, I killed it after like 5 minutes. Both with and without network.

 

I don't have /etc/cloud.

Also cloud-init command is not found.

Maybe because I did minimum ubuntu install.

Also 'etc/network/interfaces' does not exist. Probably like one above mentioned, it was moved elsewhere in recente ubuntu version
 

Any idea how to fix issue?

 

Edited April 25, 20206 yr by Alex R. Berg

1 hour ago, Alex R. Berg said:

I have this problem in my freshly installed Ubuntu 20.04 VM. When I boot without any Unraid Share, i have network access, but no network when booting with a share.
 

ip link

gives me precisely the same output with or without share in vm-settings (after boot)

my link is called 'enp2s0'

'sudo dhclient enp2s0' seems to run forever, I killed it after like 5 minutes. Both with and without network.

 

I don't have /etc/cloud.

Also cloud-init command is not found.

Maybe because I did minimum ubuntu install.

Also 'etc/network/interfaces' does not exist. Probably like one above mentioned, it was moved elsewhere in recente ubuntu version
 

Any idea how to fix issue?

 

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

Thank you Mickey. You helped, even if it was just to make me realize I kind of already found the solution, I just didn't know it.

I think something have confused me. I tried messing around with the bus after in another thread, and it didn't work. But maybe it did work. I got it working before I wrote the thread by removing the filesystem mount, but now i'm unsure wether that deletion happened, because I noticed I still have the filesystem mount. I just thought I had removed it, so I spent the afternoon messing with samba. 

Anyway long story short, here's what I did. I swapped the bus so filesystem is 0x02, and eth-interface is 0x01. Then network appear in top right corner and is available in settings in Ubuntu gui. I then added manual IPv4 address, and then it worked. With automatic DHCP it didn't get address, as verified by ifconfig and ping google.
 

 <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user'/>
      <target dir='ubuntu'/>
      <alias name='fs0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='52:54:00:03:7e:e6'/>
      <source bridge='br0'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

I just checked and now I have internet and mounting `sudo mount -t 9p -o trans=virtio mnt /mnt`.

As a side note I read in another thread that mounting like this would be faster 

sudo mount -t 9p -o msize=262144,trans=virtio,version9p2000.L,_netdev,rw mount-tag /mnt/user

 

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. 

Its obviously an unRaid issue if the multiple devices gets assigned to the same bus in the XML, generated by unRaid. It might well be more subtle issue with IPv4 not getting assigned automatically via public br0, i mean routers DHCP. Might be KVM, might be Ubuntu, might be unRaid.

 

Having the same issue on a new Debian VM.

2.5 years later. Still around.  Swapping the "bus" between the NIC and the Share works for me.

And even after 3 years buggy.

It's still happening in 2024. The mounting option doesn't work AND it breaks network on VM.

hello, I got the same problem. I add a share to a  Ubuntu 23.10 VM. 
My initial attempt to resolve the problem involved modifying the 'ntplan' file, but this did not yield any positive results
Subsequently, I attempted to change the bus on the VM's configuration, but this too did not resolve the issue.

However, I found a temporary solution by executing the following commands:
 

sudo dhclient -r
sudo dhclient
sudo ip address add  10.10.11.10/24 dev enp1s0
sudo ip link set enp1s0 up
sudo ip route add default via 10.10.10.2541

Please note that you will need to replace the IP address and interface name with the appropriate values for your specific setup.

 

However, this has resulted in the interface having two IP addresses - one obtained from 'dhclient' and the other configured through the aforementioned commands.