I am on a completely default Debian Buster installation. I have installed munin-node, which reports itself as version 2.0.49.

I have a custom plugin in /etc/munin/plugins. It is a shell script that simply cats a value from a file a user's home directory: /home/peter/value.txt.

I can netcat localhost 4949 to interact with the munin node.

If I issue a list command then my plugin is included along with all the defaults, so munin-node does recognize that the plugin exists and is executable, etc. But when I try to run the plugin by issuing a fetch command, I get a permission-denied error when the plugin tries to open the file in the user's home directory. To reiterate; the plugin itself executes, but fails to read the file in the home directory.

Some facts:

  • It works on Debian 9 (Jessie), where munin-node reports itself as version 2.0.33-1.

  • If I hack the plugin to print a hardcoded value, it works.

  • The file in the user's home directory has permissions -rw-r--r--. The home directory itself has permissions drwxr-xr-x.

  • If I munin-run the plugin from the command line as root, it works correctly.

  • If I move value.txt to /etc/munin/plugins or usr/share/munin/plugins then it works.

  • Google suggests that if a plugin works with munin-run and not with munin-node then SELinux is likely to blame. I am not running SELinux, AFAIK.

  • If I service munin-node stop and run munin-node manually on the command line as root, it works correctly.

  • htop shows that the plugin is run as root. I can add an entry to /etc/munin/plugin.conf.d and have it run as the user whose home directory it is, but that has no effect. (By which I mean; I can see that the plugin is now running as that user, but it still gets a permission-denied error).

I believe there is something about the way the service is started by Debian's /etc/init.d/munin-node scripts that is causing this. Possibly AppArmour?

1 Answer 1


The answer is that the munin-node package in Debian 10 includes /lib/systemd/system/munin-node.service, which sets ProtectHome=true. Debian 9's munin-node package does not have this file.

Setting ProtectHome=read-only is one solution, or even ProtectHome=false to include write access. However the ProtectHome flag exists for good reasons. Arranging for the plugin to read its data from elsewhere (outside of /home) is arguably a better solution.

See here for discussion of the problem as well as the security-vs-convenience tradeoff.

  • Thank you. I know I was close as if my plugin-conf.d/munin-node setting for my plugin to run as root was there id get "permission denied" but with it "file not found" whehn accessing files by chance in my home/user dir. it seemed so strange as it should be running as root and no problems, but it was this debian systemd setting blocking it. thanks, i will instead just store my files for munin stats elsewhere. Dec 30, 2021 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.