On Friday, 26 June 2026 16:48:46 CEST Ross Burton wrote: > On 16 Jun 2026, at 15:40, Andreas Mützel via lists.openembedded.org > <[email protected]> wrote: > > > > systemd v256+ automatically creates the upperdir and workdir when > > starting an overlayfs mount unit. The directories created this way are > > owned by root:root; this behaviour differs from the previously used > > helper unit, which explicitly applied the ownership of the lowerdir to > > the upperdir. > > I’d prefer not to have to carry unit files that mostly duplicates code that > systemd has integrated. Have you spoken to systemd upstream about changing > the behaviour there, or adding some options?
No, I haven't, sorry. In short: I suspected the original change to be a regression in oe-core, so my idea was to fix it here. The long story: When upgrading a BSP to wrynose, I noticed that services now failed to start because they relied on the previous behaviour (upperdir inherits owner of lowerdir). See my original mail from Jun 11, "overlayfs.bbclass: upperdir ownership change in wrynose"; Yoann's answer seemed to confirm my suspicion. So my idea was to restore the previous behaviour, but only for the cases where it is explicitly needed. In general, there are already some alternative approaches to configure the upperdir. Systemd already offers (at least): - DirectoryMode=<mode> in the mount unit can be used to control the mode at directory creation time - StateDirectory=<path> in the unit of the service that uses the overlay: makes the directory owned by the service user when the service is started, optionally with a mode as given by StateDirectoryMode= - tmpfiles.d: can be used, but states in the manpage that a StateDirectory= in the service unit is best used for service-local data All those options have in common that the ownership and permissions are defined by the unit/config, not by the actual properties of the lowerdir. (Which may be desired or not.) DirectoryMode is closest to the previous behaviour for cases where these properties are static, but there is no corresponding DirectoryUser/DirectoryGroup property. StateDirectory (and similar properties) get complicated for directories shared between multiple services. And the tmpfiles.d solution relies on the tmpfiles service instead of being tied to the overlayfs unit itself. I am not sure if inheriting the lowerdir permissions is always better or worse than using one of the systemd-provided options. In the BSP in question, the systemd-provided options would actually work fine for most applications. But is there already a "best-practice" way of configuring the overlayfs permissions? BTW: I tried to open an account on the bug tracker to discuss this, but haven't received any reaction to my request. So I implemented a minimal solution to start this conversation here. I hope this is fine :-) Andreas
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#239732): https://lists.openembedded.org/g/openembedded-core/message/239732 Mute This Topic: https://lists.openembedded.org/mt/119834259/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
