-bash: ifup: command not found means nothing on the server provides ifup. On current Debian and Ubuntu cloud images that is the default, because netplan and systemd-networkd run the network and the ifupdown package is not installed. Debian adds a second cause: a regular user’s PATH there has no /usr/sbin, so ifup and ifdown stay “not found” for your user even after the install.
There are two fixes. Use the tools the system already runs (networkctl, ip and netplan), our pick on any netplan host, or install ifupdown and give it a stanza per interface. Below are both, the exact ifup command not found and ifdown command not found strings each distro prints, and an Ubuntu trap that leaves a NIC with two IP addresses. We tested this in October 2026 on Debian 13 and Ubuntu 26.04.1 LTS cloud images, each with a spare NIC to cycle.
Check which network stack the server runs
Before you install anything, find out what manages the interfaces, because the right replacement for ifup depends on it. Three read-only checks answer that: whether the classic /etc/network/interfaces file exists, whether netplan has a config, and which network service is active:
ls /etc/network/interfaces 2>&1; ls /etc/netplan/; systemctl is-active systemd-networkd NetworkManager networkingBoth lab servers printed the same thing. There is no interfaces file, cloud-init wrote a netplan file, and systemd-networkd is the only active service (NetworkManager and networking both report inactive), so ifupdown would have nothing to read even if it were installed. That combination is normal on cloud images, so the error points at a missing package and not at a broken network.
ls: cannot access '/etc/network/interfaces': No such file or directory
50-cloud-init.yaml
active
inactive
inactiveRead your own result against these three cases, since each one points to a different fix:
systemd-networkdactive plus a file in/etc/netplan: use networkctl and netplanNetworkManageractive: use nmcli (not covered by this lab)networkingactive and/etc/network/interfacespresent: ifupdown is installed, so check your PATH
A desktop install usually lands in the second case, and our nmcli guide for Ubuntu and Debian covers that stack. A Debian server installed from the netinst or DVD installer typically lands in the third case instead. We did not test that path, so check with dpkg -l ifupdown before you assume either way.
Next, networkctl list shows every link and whether networkd manages it. In the Debian lab, eth0 carries SSH and ens19 is the spare NIC that every later example cycles:
networkctl list --no-pagerThe SETUP column is the one to read. configured means a network file owns the link, and unmanaged means networkd is not touching it. So on this Debian box eth0 has a netplan config and ens19 has none. On Ubuntu 26.04 the spare NIC already showed configured at boot, for a reason covered in the section on stopping Ubuntu from giving the NIC two addresses:
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 ens19 ether off unmanaged
3 links listed.Run every up and down test on a NIC that does not carry your SSH session, or from the VM console. Take down the interface you’re logged in through and you lose the session that would bring it back. Replace ens19 with your own interface name (from ip -br link) in the commands and files that follow.
Match the ifup command not found message
Debian and Ubuntu word the error differently, and the wording tells you which cause you hit. A plain shell error is a PATH lookup that failed. A sudo error means the binary isn’t anywhere in sudo’s secure path, so the package really is missing.
-bash: ifup: command not found
This is the Debian message from an interactive login shell, and from a script you’ll see bash: line 1: ifup: command not found with exit code 127. Debian’s cloud image has no command-not-found handler (/usr/lib/command-not-found doesn’t exist), so you get the bare error and no install hint:
ifup ens19On Debian this message has two possible causes, and installing the package fixes only one of them. The other is the PATH, which the sudo test below tells apart.
-bash: ifup: command not foundIf you still see it after ifupdown is installed, the package is fine and your shell simply is not looking in /usr/sbin. That case has its own fix in the install section, because no amount of reinstalling changes the result. A missing package and a missing PATH entry print the same line, so the sudo test is how you tell them apart.
sudo: ifup: command not found
Test through sudo with a command that changes nothing. Asking for the version and the package state is enough, and it can’t touch an interface even on a server where ifupdown does manage the SSH link:
sudo ifup --version; echo rc=$?; dpkg -l ifupdown; echo rc=$?When the package is missing, sudo stops before ifup could run, whatever arguments you pass, because it searched every sbin directory on its secure path and found nothing. Debian’s sudo prints the name bare and exits 1, and the ifdown form reads the same with its own name. This run is from the Debian server after ifupdown was purged:
rc=1
sudo: ifup: command not found
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
un ifupdown <none> <none> (no description available)
rc=0That rules out the PATH cause, so the only fix left is the package or its replacement. The un status means dpkg knows the name but nothing is installed, which is what a purge leaves behind. On a host that never had ifupdown, dpkg reports no matching package at all instead, so read “un, or no match” as the same answer. When ifupdown is installed, the same test prints ifup version with a package version, and dpkg -l shows an ii line for the package.
Ubuntu 26.04 uses sudo-rs, which quotes the name. Our lab hit it with sudo ifup ens19; echo rc=$? against the spare NIC, which returned the ifup half of the message and exit code 1:
sudo: 'ifup': command not found
rc=1Ubuntu’s user PATH already includes /usr/sbin, so on Ubuntu this sudo message and the plain shell error both mean the same thing: install ifupdown or use networkctl.
Command ‘ifup’ not found, but can be installed with:
Ubuntu ships the command-not-found helper, so typing ifup in an interactive shell gets you a list of packages instead of a bare error. It offers three, and only the first is the classic tool most scripts and old guides expect:
Command 'ifup' not found, but can be installed with:
sudo apt install ifupdown # version 0.8.43ubuntu3, or
sudo apt install ifupdown-ng-compat # version 0.12.1-8
sudo apt install netscript-2.4 # version 5.5.5+nmu3build1We tested only ifupdown. The ifupdown-ng compatibility package and netscript were not tried here, so if you take the hint, take the first line. It is also the only one whose behavior the rest of this guide describes, so the stanza and state files below match what you get.
Add the interface to netplan
The netplan YAML is where you make a config change that survives a reboot, the same job a stanza in /etc/network/interfaces used to do. Netplan renders it into a systemd-networkd file under /run/systemd/network/, which is why networkctl can then take the link up and down. Do this first if networkctl list showed your NIC as unmanaged. The netplan documentation lists every key. Create a file for the spare NIC:
sudo vim /etc/netplan/60-ens19.yamlWe used the same file on both servers, a plain DHCP config for one interface. Keep the two-space indents exactly, because netplan reads YAML and a misplaced key fails the apply.
network:
version: 2
ethernets:
ens19:
dhcp4: trueNetplan config can hold Wi-Fi keys and other secrets, so the lab set the file to root-only mode 600 before applying it. Run netplan apply straight after, since the YAML takes effect only when you apply it or at the next boot:
sudo chmod 600 /etc/netplan/60-ens19.yaml
sudo netplan applyWithin about 6 seconds ens19 moved from unmanaged to routable, with a DHCP address on Debian. That configured state is what lets networkctl take the link up and down, so the next section depends on this file.
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 ens19 ether routable configured
3 links listed.
ens19 UP 10.0.1.51/24 metric 100 fe80::be24:11ff:fe11:f52d/64When you edit netplan over SSH, use netplan try instead of apply. It applies the change, waits for you to press Enter, and rolls back on its own if you don’t, which saves you when a typo takes down the interface you’re logged in through. With no input it reverted after the 5-second timeout and still exited 0:
sudo netplan try --timeout 5The countdown prints on a single line, then the rollback. Press Enter inside the window when the change is good, and netplan keeps it.
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 5 secondsChanges will revert in 4 secondsChanges will revert in 3 secondsChanges will revert in 2 secondsChanges will revert in 1 seconds
Reverting.Static addresses, bridges and VLANs use the same file with more keys. Our netplan static IP guide covers addresses, routes and DNS on Ubuntu.
Bring interfaces up and down with networkctl
On a netplan host, networkctl down and networkctl up are the ifdown and ifup you are looking for, and they need no extra package. They act on links that systemd-networkd manages, which ens19 now is. Take the managed link down:
sudo networkctl down ens19Give it a few seconds before you check. Straight after the command the address was still listed, and it was gone once the state settled about 3 seconds later, so a check run too early looks like a failure that is not one.
networkctl list --no-pager | grep ens19; ip -br addr show ens19off configured is the healthy “down” state: the link is off but networkd still owns its config, so up brings everything back. An off unmanaged state would mean networkd has no config for the link, so up would only raise the link without an address:
3 ens19 ether off configured
ens19 DOWNBring it back up and check the address.
sudo networkctl up ens19
ip -br addr show ens19The DHCP address returned in about a second on Debian. If it stays empty, the link has no netplan config and you’ll only see an IPv6 link-local address, so an empty result after up sends you back to the netplan section rather than to a reinstall:
ens19 UP 10.0.1.51/24 metric 100 fe80::be24:11ff:fe11:f52d/64That’s exactly what happened when we ran networkctl up on ens19 before it had a config: the link went UP, networkctl reported it degraded unmanaged, and no IPv4 address came. Two more networkctl verbs cover the other reasons people reach for ifdown and ifup. reconfigure re-applies the configuration networkd already has loaded, and renew asks the DHCP server for a fresh lease. Both returned 0 in the lab, and reconfiguring eth0, the SSH link, kept its address and the session:
sudo networkctl reconfigure ens19
sudo networkctl renew ens19Reconfigure does not pick up edited files: the networkctl manual says it does not reload .netdev or .network files. After you edit netplan, run sudo netplan apply (or netplan try). After you hand-edit a file in /etc/systemd/network/, run sudo networkctl reload first, then reconfigure the link, so networkd works from the new file.
Avoid ip link set for this job on a managed link. sudo ip link set dev ens19 down left the NIC at off configured with no address five seconds later. It did not come back on its own, and only sudo networkctl up ens19 restored it. Running ip link set dev ens19 up toggles the link and nothing else, so on an unconfigured NIC it gets you the link-local address and no DHCP. If you are coming from ifconfig as well as ifup, the ifconfig vs ip usage guide maps the rest of the old commands.
Install ifupdown for the classic commands
Install ifupdown when you have scripts, runbooks or muscle memory that call ifup and ifdown, or you want a NIC configured from an /etc/network/interfaces stanza. Debian carries it in main next to two rewrites, ifupdown2 and ifupdown-ng. Ubuntu carries ifupdown and ifupdown-ng in universe and has no ifupdown2 at all. Neither rewrite was tested here:
| Package | Debian 13 candidate | Ubuntu 26.04 candidate |
|---|---|---|
| ifupdown | 0.8.44+deb13u1 | 0.8.43ubuntu3 (universe) |
| ifupdown2 | 3.0.0-1.3 | (none) |
| ifupdown-ng | 0.12.1-7 | 0.12.1-8 (universe) |
Plain ifupdown is the one that exists on both, and it’s the one the error hints and old guides mean. It pulled in no other package on either server, although on Ubuntu it needs the universe component enabled, which the cloud image had:
sudo apt update
sudo apt install ifupdownApt suggests ppp and rdnssd but installs only the one package.
Suggested packages:
ppp rdnssd
The following NEW packages will be installed:
ifupdown
Setting up ifupdown (0.8.44+deb13u1) ...The install changes very little on a netplan host, which is why the errors that follow surprise people:
/etc/network/interfaceswith two comment lines and asource /etc/network/interfaces.d/*linenetworking.serviceenabled for the next boot- no changes to netplan or systemd-networkd
Your existing interfaces stay with systemd-networkd, and ifupdown starts with no interfaces of its own. That is why the first ifup after the install fails, as shown below, even though the package installed cleanly.
Fix the Debian PATH trap
On Debian a regular user’s PATH is /usr/local/bin:/usr/bin:/bin:/usr/games, with no sbin directory in it. ifup, ifdown and ifquery all live in /usr/sbin, so even after the install the plain command still fails for your user. Ubuntu doesn’t have this problem, because its user PATH already includes /usr/sbin and /sbin. This capture from the Debian server shows the error before the install, the package candidates, and the PATH trap after it:
The binary is there and /usr/sbin/ifup --version answers, yet ifup --version still exits 127. Through sudo the same check returns 0 (the last command in the capture ran after the stanza further down existed, which is why ens19 is listed). Run it the way it is meant to run, as root. sudo searches its own secure path, which on Debian is printed by this command.
sudo sh -c "echo \$PATH"That list includes /usr/sbin, so sudo ifup finds the binary while your own shell does not. It also explains why the sudo form of the error is the reliable test: if sudo cannot find ifup, nothing on the system provides it.
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binBringing an interface up or down needs root anyway, so sudo ifup ens19 is the right habit. Once ifupdown is installed, a read-only check also works through the full path, which ran as the regular user in our lab:
/usr/sbin/ifquery --listIt prints every interface ifupdown has a stanza for. Right after the install that is only lo, which matters next, because ifup refuses every interface that has no stanza, even after a clean install.
ifup: unknown interface ens19
Most people hit this first after the install, and it is expected. ifupdown only knows interfaces that have a stanza, and it doesn’t read netplan, so even eth0 is unknown to it:
sudo ifup ens19; echo rc=$?; sudo ifdown ens19; echo rc=$?; sudo ifquery --listBoth commands fail with exit code 1, and ifquery --list returns only the loopback. ifupdown has no idea eth0 exists either, even though that NIC is carrying your SSH session.
ifup: unknown interface ens19
rc=1
ifdown: unknown interface ens19
rc=1
loTo hand a NIC to ifupdown, take it away from netplan first, so two stacks do not configure the same link. Do not do this to the interface that carries your SSH session unless you are on the console, because removing its netplan entry drops the address you are connected through. On the spare NIC we removed the netplan file from earlier and re-applied:
sudo rm /etc/netplan/60-ens19.yaml
sudo netplan applyOn Ubuntu 26.04, run the three steps from the section on stopping Ubuntu from giving the NIC two addresses (the unmanaged file, networkctl reload, then ip addr flush) before or right after this stanza, or the NIC ends up with two addresses. We applied them after the first ifup in the lab. Then create the stanza file:
sudo vim /etc/network/interfaces.d/ens19Two lines are enough. auto brings the interface up at boot through networking.service, and inet dhcp hands its addressing to a DHCP client:
auto ens19
iface ens19 inet dhcpCheck that ifupdown now sees it with sudo ifquery --list, which should print lo and ens19, then bring it up.
sudo ifup ens19ifup runs dhcpcd for the lease. Both cloud images already had dhcpcd-base installed, and isc-dhcp-client wasn’t involved. Look for the leased line:
dhcpcd-10.1.0 starting
DUID 00:01:00:01:32:6b:15:df:bc:24:11:11:f5:2d
ens19: IAID 11:11:f5:2d
ens19: soliciting an IPv6 router
ens19: soliciting a DHCP lease
ens19: offered 10.0.1.51 from 10.0.1.1
ens19: probing address 10.0.1.51/24
ens19: leased 10.0.1.51 for 7200 seconds
ens19: adding route to 10.0.1.0/24
ens19: adding default route via 10.0.1.1
Dropped protocol specifier '.dhcp' from 'ens19.dhcp'. Using 'ens19' (ifindex=3).Note the adding default route line. A dhcp stanza installs a second default route through the new NIC, which you can see in the routing table:
ip routeTraffic still leaves through eth0, because its route has metric 100 against 1003 for ens19. That is fine for a spare NIC on the same LAN, but if the second network has a different gateway, plan which one should win before you rely on it:
default via 10.0.1.1 dev eth0 proto dhcp src 10.0.1.50 metric 100
default via 10.0.1.1 dev ens19 proto dhcp src 10.0.1.51 metric 1003
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.50 metric 100
10.0.1.0/24 dev ens19 proto dhcp scope link src 10.0.1.51 metric 1003
10.0.1.1 dev eth0 proto dhcp scope link src 10.0.1.50 metric 100 The two default via lines are the ones to watch. If the gateway on the second NIC is not one you trust for outbound traffic, a static stanza without a gateway avoids the extra route, although this lab only tested dhcp.
ifdown: interface ens19 not configured
ifupdown tracks what it brought up in /run/network/ifstate.ens19, and it refuses to repeat itself. Running ifdown on an interface that’s already down prints this message, and ifup on one that’s already up prints ifup: interface ens19 already configured and changes nothing. Both exit 0, so they’re notices, not failures:
sudo ifdown ens19
sudo ifdown ens19The first call stops dhcpcd, and the second one finds nothing to do because the state file is already gone. Scripts that call ifdown twice therefore keep working, but to apply an edited stanza you need ifdown then ifup, since a bare ifup on a running interface is a no-op.
sending signal ALRM to pid 16229
waiting for pid 16229 to exit
ifdown: interface ens19 not configuredIf you see “not configured” for an interface that’s clearly up, ifupdown did not bring it up. Netplan or networkd did, and networkctl down is the command for it. After a reboot both stacks came back on Debian: eth0 from netplan and networkd, ens19 from networking.service, and networkctl listed ens19 as routable unmanaged. If you’d rather move the whole server off networkd, read up on disabling systemd-networkd first, and do it from the console.
Stop Ubuntu from giving the NIC two addresses
On Ubuntu 26.04 the same stanza produced a NIC with two IPv4 addresses. The cloud image we tested boots with a dracut initramfs, which generates /run/systemd/network/zzzz-dracut-default.network at boot. That file is a catch-all with DHCP on: Kind=!* and Type=!loopback match every non-loopback interface without a kind, which in practice means every physical NIC. So the spare NIC was already UP with a networkd lease before ifupdown ever touched it, and ifup added a second lease from dhcpcd on top:
The first address (metric 1024) belongs to networkd, which networkctl status confirms by naming the dracut file as the link’s network file. The second, marked secondary noprefixroute, is dhcpcd’s. Two DHCP clients now hold separate leases on one NIC. On the Debian server, ls /run/systemd/network/ listed only the two 10-netplan-eth0 files and /etc/systemd/network/ was empty, which is why its spare NIC sat at off unmanaged after boot. We didn’t test Ubuntu 24.04, so on any release run ls /run/systemd/network/ and look for that file before handing a NIC to ifupdown.
To stop it, tell networkd to leave that interface alone with a higher-priority network file. networkd sorts .network files by name and applies the first one that matches, as the systemd.network manual describes. A name starting with 05- therefore beats zzzz-.
sudo vim /etc/systemd/network/05-ens19-unmanaged.networkMatch the interface by name and mark it unmanaged. Put your NIC’s name in both the file name and the Name= line, so the file is easy to find when you add the next interface.
[Match]
Name=ens19
[Link]
Unmanaged=yesReload networkd so it reads the new file, then cycle the interface through ifupdown. The flush clears the address networkd leased, so only the dhcpcd lease comes back:
sudo networkctl reload
sudo ifdown ens19
sudo ip addr flush dev ens19
sudo ifup ens19Confirm networkd has let go and only one address is left. The SETUP column should now read unmanaged instead of configured.
networkctl list --no-pager | grep ens19; ip -4 -br addr show ens19The link now reads unmanaged with the single address dhcpcd leased. With networkd out of the way there is one DHCP client and one lease on the NIC, so the address no longer depends on which client renewed last.
3 ens19 ether routable unmanaged
ens19 UP 10.0.1.61/24It held across a reboot. The dracut file was generated again at boot, but our 05- file still won, and ens19 came back with one address and the same metric 1003 default route seen on Debian. So the unmanaged file is a one-time step per interface, and you only revisit it when you rename or add a NIC.
Translate ifup and ifdown to networkctl, ip and netplan
Most ifup and ifdown habits have a direct equivalent on a netplan host. These are the ones we ran in the lab, with ens19 standing in for your interface. NetworkManager hosts use nmcli instead, which this lab did not cover:
| Task | ifupdown | netplan + systemd-networkd |
|---|---|---|
| Bring an interface up | sudo ifup ens19 | sudo networkctl up ens19 |
| Take an interface down | sudo ifdown ens19 | sudo networkctl down ens19 |
| Re-apply the loaded config | sudo ifdown ens19 && sudo ifup ens19 | sudo networkctl reconfigure ens19 |
| Renew the DHCP lease | sudo ifdown ens19 && sudo ifup ens19 | sudo networkctl renew ens19 |
| Apply an edited config file | sudo ifdown ens19 && sudo ifup ens19 | sudo netplan apply or sudo netplan try (hand-edited networkd file: sudo networkctl reload, then reconfigure) |
| List interfaces | sudo ifquery --list (stanzas only) | networkctl list (every link, with its SETUP state) |
| Persistent config file | /etc/network/interfaces.d/ens19 | /etc/netplan/60-ens19.yaml |
| Where state lives | /run/network/ifstate.ens19 | networkctl status ens19 |
| Link only, no addressing | sudo ip link set dev ens19 up | sudo ip link set dev ens19 up |
On a server that already runs netplan, we’d use the right-hand column and leave ifupdown uninstalled, because one network stack per interface leaves one place to look when a link misbehaves. Install ifupdown when existing scripts need it, give it only the interfaces it owns, and on Ubuntu 26.04 add the unmanaged file before the first ifup. The older netplan management guide has more YAML examples, and if ifconfig is missing too, the same images lack net-tools, which our ifconfig install guide covers.
