We monitor SR capacity with Zabbix, which runs as an unprivileged user. Where the parent is 0700 the agent can't traverse it, so the SR checks fail with:

Cannot obtain filesystem information: [13] Permission denied

Two hosts, both on the same XCP-ng version (8.3 LTS). The first works, the second does not.

Host A, working:

Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

Host B, broken:

Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)

Nobody has changed it by hand, and /run is tmpfs, so the directory gets recreated on every boot.

FileSR.py creates each SR's own mount directory at 0700, which looks like the source of it:

grep -n "makedirs\|mkdir\|chmod\|0o7\|0700\|0755" /opt/xensource/sm/FileSR.py
127:                    util.ioretry(lambda: os.mkdir(self.remotepath))
178:                util.ioretry(lambda: util.makedirs(self.path, mode=0o700))
188:                os.chmod(self.path, mode=0o0700)

self.path is /run/sr-mount/<sr-uuid>, so 0700 on the SR's own directory is intentional. But util.makedirs is recursive and defaults to mode=0o777:

grep -n "def makedirs\|chmod" /opt/xensource/sm/util.py
623:def makedirs(name, mode=0o777):
636:                os.chmod(name, mode)

My reading: if a local EXT SR attaches before /run/sr-mount exists, makedirs(self.path, mode=0o700) creates the parent in the same call and the parent inherits 0700. On hosts where something else creates the parent first at the default mode, whatever attaches later finds it already there and leaves it alone.

What we have tried, none of it ideal. A plain chmod 755 /run/sr-mount works but doesn't survive a reboot. An ExecStartPost drop-in on xs-sm.service persists but can lose the race if an SR attaches after the service reports started. We're now testing a systemd .path unit watching /run/sr-mount that re-applies 0755 whenever it changes, which sidesteps the ordering question, but it's a workaround rather than a fix and won't survive a major version upgrade.

I'm sure someone else must have come across this issue so I'm hoping there's a better fix.

Sudo doesn't help. vfs.fs.size stats the path in-process, and df with no path argument still stats each filesystem, so the SR rows drop with no error for a non-root user.

Questions:

1. Is 0755 the intended mode for the parent /run/sr-mount, with the 0700 an unintended side effect of the recursive makedirs? Or is 0700 on the parent deliberate too, making the 0755 hosts the anomaly?
2. Does anything create the parent or set its mode explicitly, or does it only ever appear as a by-product of the first SR attach?
3. Has anyone else hit this while monitoring SR capacity with a non-root agent, and how did you handle it?

Is there a supported way to have the parent set at 0755 consistently, or should this be raised as a bug against sm?