# Running UDEV rule to change interface names

**URL:** <https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895>\
**Category:** Product support\
**Tags:** network\
**Created:** [September 7, 2023, 3:13pm UTC](https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895 "2023-09-07T15:13:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jcv](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@jcv](https://forums.balena.io/u/jcv)\
**Post date:** [September 7, 2023, 3:13pm UTC](https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895/1 "2023-09-07T15:13:08Z")

</div>

I am attempting to rename the network interfaces on a device using udev rules. I know that this can be done by modifying the config.json but we would like for it to be done at runtime.

I have created a rule /etc/udev/rules.d/70-persistent-net.rules:

```auto
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="enp6s0", NAME="enp3s0"

```

If I try to run the udev rules using `udevadm control --reload-rules && udevadm trigger` the rule errors out because the resource is being busy. In order to fix this, I can take the interface down using `ip link set down enp6s0` and then running the udevadm command works and the interface is renamed.

The issue comes with that this rule is not persistent and should take affect on every reboot but does not seem to work. I am looking for any help or suggestions on how to get this to work.

---

<div class="post-metadata">

**Author:** ![TJvV](https://avatars.discourse-cdn.com/v4/letter/t/858c86/32.png) [@TJvV](https://forums.balena.io/u/TJvV)\
**Post date:** [September 8, 2023, 7:08am UTC](https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895/2 "2023-09-08T07:08:48Z")

</div>

Hi,

> The issue comes with that this rule is not persistent and should take affect on every reboot but does not seem to work

Could it be you´re suffering from the same issue described [here](https://forums.balena.io/t/rs232-udev-rule-not-working-on-startup/368843/1)?  
The main solution there was to change `ACTION=="add"` to `ACTION=="add|change"`

---

<div class="post-metadata">

**Author:** ![jcv](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@jcv](https://forums.balena.io/u/jcv)\
**Post date:** [September 12, 2023, 5:51pm UTC](https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895/3 "2023-09-12T17:51:44Z")

</div>

This unfortunately did not work either.

---

<div class="post-metadata">

**Author:** ![mpous](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/mpous/32/4742_2.png) [@mpous](https://forums.balena.io/u/mpous)\
**Post date:** [September 13, 2023, 9:19am UTC](https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895/4 "2023-09-13T09:19:00Z")

</div>

Hello @jcv could you please confirm what device are you using? On the other hand, what balenaOS version are you using?

---

<div class="post-metadata">

**Author:** ![the-real-kenna](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/the-real-kenna/32/9598_2.png) [@the-real-kenna](https://forums.balena.io/u/the-real-kenna)\
**Post date:** [September 21, 2023, 6:36pm UTC](https://forums.balena.io/t/running-udev-rule-to-change-interface-names/368895/6 "2023-09-21T18:36:34Z")

</div>

This discussion continued in our Paid Support queue, so I wanted to share the final outcome publicly for others’ benefit.

Setting up `udev` rules in the `config.json` remains the best solution to-date: [GitHub - balena-os/meta-balena: A collection of Yocto layers used to build balenaOS images](https://github.com/balena-os/meta-balena#udevrules)

Our thought process is best described by one of the balena engineers in his own words:

> I unfortunately don’t see much of a clean way to achieve your goal using udev rules from a container. As far as I understand, what is happening is:
> 
> 1. The rule doesn’t trigger at boot time because the “add” event is triggered earlier in the startup process, before the container has a chance to run.
> 2. I did a quick search and I don’t think network interfaces generate “change” events, so this wouldn’t help either.
> 3. Running `udevadm trigger` effectively replay the events and give the rules another change to trigger, but (as you noticed) the rule will fail if the network interface is already up.
> 
> I imagine it would be technically possible to run some script on the container that would circumvent each of these obstacles, but in my opinion such solution would be quite convoluted and brittle (because we’d be essentially going against the way these things were meant to be used).

I hope the exchange is able to help others as well. 🙂