Hi,

I'm using dunfell branch 3.1.11. My wks file is generating a 4th partition which is being mounted to /data via the --rootfs-dir argument. All directories within the mounted /data are owned 1000:1000 which I believe is a contamination via my host user running the build.

I've looked around online and haven't been able to ascertain the cause, although there are a few others which seem to be the same problem:
https://www.yoctoproject.org/pipermail/yocto/2019-August/046378.html

I've seen some patches addressing similar behavior in the wks files:
[v7,02/10] wic: Fix multi images .wks with bitbake
[v2,1/2] wic: Fix permissions when using exclude or include path

I've also found this post from a user that says "Just saw that the issue is that you can't use rootfs-dir with a subfolder". I am at a complete loss for where they have seen that information... perhaps I can't see the forest for the trees.

So I'm wondering if this is a bug, or if I have done something drastically incorrect? I have thrown a fair chunk of time at the issue, and in the end all I could do is write a script that runs on first boot to chown the directories and set permissions as we need. Could someone weigh in please? I'd love to assist in writing a patch but looking at some of the code, I literally have no idea where to start...

My wks file:

part /boot --source bootimg-partition --fstype=vfat --label boot --active --align 1024  --use-uuid
part / --source rootfs --fstype=ext4 --label A --align 1024 --use-uuid
part --source rootfs --fstype=ext4 --label B --align 1024 --use-uuid
part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --fstype=ext4 --label data --align 1024  --use-uuid --size 10

Image recipe excerpt, I realize this shouldn't go in a ROOTFS_POSTPROCESS_COMMAND necessarily, this is just an artifact of my testing:

ROOTFS_POSTPROCESS_COMMAND += " chmod_dirs;"

chmod_dirs() {
    mkdir -p ${IMAGE_ROOTFS}/data/firmware
    chown 0:421 ${IMAGE_ROOTFS}/data/firmware
    chmod 0770  ${IMAGE_ROOTFS}/data/firmware
    lnr ${IMAGE_ROOTFS}/data/firmware ${IMAGE_ROOTFS}/opt/Firmware
}

Resulting folder in image:
root@sgc30cube:~# ls -la /data
drwxr-xr-x    4 root     root          1024 Nov 30 09:00 .
drwxr-xr-x   21 root     root          1024 Nov 30 09:00 ..
drwxr-x---    2 1000     1000          1024 Mar  9  2018 firmware
drwx------    2 root     root         12288 Nov 30 09:00 lost+found

Is there a more elegant way to work around this issue, rather than scripted chmod/chown on the target?

Please let me know if I could provide more useful information.

Thank you,