# Adding rules to udev: easy or a consenus best practice
**URL:** https://discourse.nixos.org/t/adding-rules-to-udev-easy-or-a-consenus-best-practice/78323
**Category:** Help
**Created:** [June 17, 2026, 1:26am UTC](https://discourse.nixos.org/t/adding-rules-to-udev-easy-or-a-consenus-best-practice/78323 "2026-06-17T01:26:54Z")
**Posts on this page:** 1
**Showing post:** 12
### Author:  [@withakay](https://discourse.nixos.org/u/withakay)
#### Post date: [June 17, 2026, 11:47am UTC](https://discourse.nixos.org/t/adding-rules-to-udev-easy-or-a-consenus-best-practice/78323/12 "2026-06-17T11:47:28Z")
In principle, I agree. However in the specific case of udev rules needing uaccess, my code snippet above has a link to
>
>
> \### Describe the bug
>
> It's not possible to add rules to udev that uses \`TAG+="…uaccess"\` using \`services.udev.extraRules\`, because it adds to \`99-local.rules\`. The 99 priority is too late for \`uaccess\` to apply, as "documented" \[here\](https://github.com/systemd/systemd/issues/4288#issuecomment-348166161).
>
> There is a workaround documented \[here\](https://github.com/NixOS/nixpkgs/issues/210856).
>
> \### Steps To Reproduce
> Add a rule like:
>
> \`\`\`
> services.udev.extraRules = ''
> SUBSYSTEM=="usb", ATTRS{idVendor}=="2104", ATTRS{idProduct}=="0127", TAG+="uaccess"
> '';
> \`\`\`
>
> and observe you won't actually get user access to the device.
>
> \### Expected behavior
>
> If possible, we could change extraRules to just use a lower priority that allows uaccess (thought that may have unwanted side effects since people may actually expect it to run at the very end).
>
> At the very least it would be ideal to have the behavior/caveat clearly documented in services.udev.extraRules option and I think we could add an additional rules option that allows you to use uaccess without having to use the workaround? It took me awhile to figure out what was wrong when working through this, and I expect long term I won't be the last one.
>
> \### Notify maintainers
>
> @rnhmjoj you added the original option, and fixed the i2c issue, so maybe have some thoughts about the ideal approach. To fix the i2c issue in \[this\](https://github.com/NixOS/nixpkgs/pull/255305/files) the change was to just write a new file with a lower priority. But for a user testing a peripheral and they just want to add a rule in their config or something, it seems like being able to pass the rule to a \`services.udev\` option itself would be useful.
>
>
> \---
>
> Add a :+1: \[reaction\] to \[issues you find important\].
>
> \[reaction\]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
> \[issues you find important\]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
where I learned that “TAG uaccess” specifically needs to be set before e.g. `/nix/store/a8avqfxd649rfgfpqldja6v38ljb8fj5-systemd-260.1/lib/udev/rules.d/73-seat-late.rules`, since that is what converts the TAG into actual FACLs with “RUN builtin uaccess”. In other words, “TAG uaccess” needs to be set in a file lexically before `73-seat-late.rules`, so `99-local.rules` doesn’t cut it for this use case.
EDIT: see also [Udev regression / recommended way for udev rules?](https://discourse.nixos.org/t/udev-regression-recommended-way-for-udev-rules/73061) for more discussion on uaccess.
---
_[View the full topic](https://discourse.nixos.org/t/adding-rules-to-udev-easy-or-a-consenus-best-practice/78323)._