NetworkManager does not manage wired connection

[Diego]

NetworkManager does not manage my wired eth0 connection, no matter how I set /etc/network/interfaces or /etc/NetworkManager/NetworkManager.conf

Using ubuntu 16.04, /etc/network/interfaces only managed lo, and [ifupdown] section of NetworkManager.conf had set managed=false.

With these same settings, after upgrading to ubuntu 16.10, eth0 appears as unmanaged in nm-applet.

If I modify /etc/network/interfaces and add

auto eth0
iface eth0 inet dhcp

And set managed=true in NetworkManager.conf [ifupdown] section, eth0 is still unmanaged despite it does get an IP from DHCP server.

This is happening in my five computers (two laptops and three desktops).

[Aron Xu (happyaron)]

Can you provide your NetworkManager.conf as well as your /etc/network/interface file? Normally these two files should look like this:

1. NetworkManager.conf:
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

[ifupdown]
managed=false

2. interfaces:
auto lo
iface lo inet loopback

That is to say, have dnsmasq and ifupdown plugins enabled and set [ifupdown] to "managed=false", at the same time don't include anything other than "lo" in /etc/network/interfaces.

[Diego (gran-diego)]

My /etc/network/interfaces and /etc/NetworkManager/NetworkManager.conf are just as you stated.

[Diego (gran-diego)]

And here is NetworkManager.conf

[Serious Diman (seriousdiman)]

After upgrade to Ubuntu 16.10 from 15.04 or 15.10 (I can't remember). Same here. NetworkManager does not manage my wired eth0 connection.
/etc/network/interfaces and /etc/NetworkManager/NetworkManager.conf exactly as in "Aron Xu (happyaron) wrote on 2017-01-26" post.
Additionally my NetworkManager shows previously working bluetooth-modem connection "device not managed."

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Diego (gran-diego)]

After pulling my hair for several days, I found this:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638842

/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf has the following content:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan

Removing the file and restarting NetworkManager did the trick.

[Diego (gran-diego)]

Ok, just kept on reading bug report 1638842. There's no need to remove the file, just create an empty one

sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf

and restart NetworkManager

[Serious Diman (seriousdiman)]

Diego, thanks a lot! That did the trick! After removing the file (/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf) management of wired and bluetooth modem connections is back!

[brad (dragonsawareness)]

Fixed via comment 7

[gerardo (geestbos)]

Same problem after an upgrade from 16.04 to 16.10 via "do-release-upgrade". However in my case the issue occurred not for a Wired connection, but for a Mobile Broadband connection (device ttyUSB2 of type gsm over interface ppp0). Comment 7 fixed the issue.

[Raphaël Jakse (raphael-jakse)]

Bug #1638842 has been marked as a duplicate of this one, and also has been marked Won't Fix (before this bug was reported). So if we want the current behavior to be changed, we need to discuss.

Reason of the current behavior is given in Comment 7 of Bug #1638842: “On desktop images we want NM to manage everything, thus the installer creates /etc/NetworkManager/conf.d/10-globally-managed-devices.conf. But on a server, container, or similar environment we do NOT want NM to suddenly take over existing connections from netplan, networkd, or ifupdown -- there it should be restricted to wifi and 3G.”

I agree with the idea and I can imagine that even if I cannot think of a case where NM is installed in a container / on a server without wanting it to manage connections, the current behavior works around a real problem that as been encountered and that chroot installation of Ubuntu Desktops might have been forgotten in the process.

Now, installing Ubuntu using chroot is convenient and the easiest method is some cases, and as we can see in the comments here, people really do it so this should work as expected. In this setting, the current behavior is confusing. By default, nothing shows that NM is configured not to manage wired and Bluetooth connection. I lost almost a day because of this. It should at least be explicit in the configuration and in the logs. And NM changing its behavior because an empty configuration file exists at /etc/NetworkManager/conf.d/10-globally-managed-devices.conf seems weird to me.

I agree that solving the initial problem is probably important, but I think that breaking things so badly for people installing Ubuntu using chroot is wrong and that the installation of Ubuntu should be a process that remains simple and intuitive. Making the Ubuntu installer create /etc/NetworkManager/conf.d/10-globally-managed-devices.conf and make NM work as expected when this file exists looks like a hack to me, and a fragile behavior.

A better solution might be to make network-manager manage connections as expected when *-desktop packages are installed. But it is not sufficient as some people don't install these packages in their desktop setup to avoid installing things they don't use.

[Stephane Epardaud (stef-inforealm)]

Got hit by that one and lost several hours until I found the described workaround in the duplicate issue. This is really very bad. It prevents ethernet users from using network-manager-defined VPNs too.

[WolphFang (mjoyner-vbservices)]

It took me a week to figure out why I could not get networking to work on my non-chroot desktop.

I had to add a blank file and reboot? WTF?

[Paul Smith (psmith-gnu)]

Just want to point out that "chroot installs" or netboot installs are NOT the only places this breaks. I did a a straightforward upgrade (via do-release-upgrade) from Ubuntu GNOME 16.04.n (latest packages installed) to Ubuntu GNOME 16.10, on a standard desktop system where the wired network was managed by NM before.

After the upgrade, no wired interface was available.

Luckily my desktop also has a wireless interface (which I never used before); that still worked so I could continue to search for help: it took two days on and off but I finally found this bug (I was searching NetworkManager documentation and looking through nmcli output, journalctl output, etc. but there is nothing shown anywhere about this; most likely NM should be modified so that it prints something useful to the logs if it skips interfaces due to the unmanaged-devices setting).

The solution above (replacing with an empty file) then running "sudo killall -HUP NetworkManager" caused my wired connection to immediately reappear and connect.

In any event, this change is kind of a disaster; regardless of the intentions behind it the results are far too disruptive and the reasons for the problem and the solution are far too obscure and difficult for the average desktop user to be expected to figure out.

This change should be reverted until some alternative solution that is more carefully targeted to only impact the correct set of systems can be devised and implemented.

[Michael Knepher (mknepher)]

Similar to #14, this happened to me doing do-release-upgrade to 17.04 beta after purging gnome3-team ppas. I was able to get internet connection working via some manual hacks I came across, but NetworkManager not working properly meant that Evolution thought I was offline. Finally, after 5 days, discovered this bug and executing touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf seems to have fixed things.

[Sami Olmari (olmari)]

Maybe this behaviour should be tied for example into one installing ubuntu-desktop package or equivalent? While it is true that for example in server machine having NetworkManager and it controlling stuff is generally not wanted behaviour, but when user install ubuntu in "not official" way, like debootstrap that is needed for "ZFS as root partition" installation currently, all user has first is base minimum setup and then if wanted to install ubuntu GUI, one uses basically "apt-get install ubuntu-desktop"... I think that should be deciding factor to have NM managing devices or not.

In any way, if NM is managing devices, an update in general should not change that, or ofcourse other way round too, status quo should stay.

[Martin Brook (martin.brook)]

Encountered this bug on a straightforward xubuntu desktop system after upgrading (via do-release-upgrade) from 16.04 to 16.10. The solution referred in #7 has resolved it for me. In my case, the file was absent.

[Danny B (danny.b)]

Just had this happen after an ordinary desktop upgrade from 16.04 to 16.10, had to do the touch thing, because 10-globally-managed-devices.conf was missing.

For the default user-friendly desktop linux distro option, Ubuntu seems pretty bad at this just working out of the box thing. I've had less random bugs during my several years with Gentoo, and I didn't ditch it so I could waste more of my time installing obscure kernel patches and having to configure things I don't care about.

[Courtney Rosenthal (courtneyr)]

I encountered this defect defect on an upgrade from 16.04 to 16.10. I removed the /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf file and it resolved the problem.

Any reason why a fix is not being applied?

[Courtney Rosenthal (courtneyr)]

I just upgraded 16.10 -> 17.04 and this defect still is present. The bad /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf was recreated and I had to delete it to get my wired LAN back.

[Frits Jalvingh (fjalvingh)]

Got the same issue upgrading from 16.04 to 16.10 and again from 16.10 to 17.04. Deleting the file worked. Sad that this is not fixed.

[Lincoln Rickwood (lincolnrickwood)]

On 2017-04-15 I upgraded from 16.04 to 16.10 on the way to 17.04. This issue was the one and only problem I encountered.

In my case I started the wired interface manually (sudo ifconfig enp3s0 up && sudo dhclient epn3s0), got on-line and found this page. Message 6 above worked perfectly, and it's an easy fix once one knows what to do - but not until then.

It would be a very good idea to fix this, because as observed above it's a disproportionate nuisance as it prevents web access, hindering the the search for a fix and for neophytes - exactly the people we want to get using Linux - that could drive them away.

[Stefan Leitner (s-o-l)]

I upgraded from 16.04.3 (amd64) to 17.04 directly and stumbled on this problem.

/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf had the wrong configuration:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan

setting unmanaged-devices=none in this file did the trick for me, but this is a error which IMHO needs to be fixed - the system is a Laptop with the normal Unity Desktop Environment.

[Dylan (djxvillain)]

"After pulling my hair for several days, I found this:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638842

/usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf has the following content:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan

Removing the file and restarting NetworkManager did the trick."

This worked for me. Thank you so much.

[Jacobi Kosiarek (neoshika)]

This issue is still alive and well in 2019. I encountered it while upgrading from 18.04 to 18.10.

Advice from comment six resolved it, but it wasted several hours of my time. Please apply a fix or at least more thorough log messages so that medium to low skill users like myself can solve this problem for themselves.

[Countrytx (countrytx)]

Tried fix in #6 but to no avail. Have this bug in 19.1 appear after a week from install date. I thought that Pi-Hole may have caused an issue but have not found a correlation yet.

I am getting an IP from the DHCP server.

[Kent Lion (klsu)]

I'm posting here instead of the bug at: https://bugs.launchpad.net/bugs/1676547
because it got me on the path that may have solved the problem (time will tell).
My /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf also contained:
[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan
When I cleared it out and rebooted, it was still empty and the problem was still there. At that point, I noticed that when I clicked on the Network Manager applet (↑↓) it displayed the lines:
Ethernet Network (gray title)
Wired connection 1
Disconnect
enp0s25
VPN Connections
Enable Networking (checkbox)
Connection Information
Edit Connections...

But the machine has only one ethernet card, so I chose Edit Connections... and changed the connection name to the device name enp0s25. Using ifdown -a worked fine, but ifup -a gave me a long pause followed by:
sudo unable to resolve host [hostname]: Resource temporarily unavailable
When I then clicked on the Network Manager applet it showed enp0s25 above AND below Disconnect. When I then clicked Disconnect and then clicked enp0s25, it reconnected just fine. If I delete or restore the original /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf, it stops working; the file must be empty. On the machine I'm typing this on (also updated Bionic 64), /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf is not empty, but I don't do file sharing on it. Now that the other machine is working, I find I can access its shared folders on my network without a problem.

So this bug probably has more than one cause. It's as if network connection information is being taken from at least 2 different locations, and one or more of them has/have been forgotten but should be gone.

I do note that when I click Edit Connections... the connection information does not necessarily agree with what's in /etc/network/interfaces, in particular netmask refuses to keep the value 255.255.255.0 and reverts to 24 (could 24 refer to /24 in 192.168.15.109/24 ?), which is not the netmask /etc/network/interfaces requires for a static IP setting.

My problem began with a clean install from a freshly downloaded ISO of Xubuntu 18.04 LTS 64 bit desktop (not server). Networking and Internet worked, but while setting it up for file sharing over the network (as the machine it replaced had done), I eventually lost all network access, and the network manager applet refused to connect, even when it said it "connection established"...before changing to say "disconnected". I previously reported a bug that suddenly disappeared by itself for a few months and that then recently reappeared: after some minutes connected to the Internet, my network connection would suddenly disconnect, and I'd have to reconnect it in the Network Manager applet. So I just made the change to it's name on that machine, and we'll see if that solves the problem or not (it's a pain to reproduce, because it requires rebooting and waiting an unknown amount of time.

Getting file sharing in Linux is like finding an Android app: multiple choices to try, only to discover that none (or almost none) does the minimum that is reasonable to expect from it.