5360 2013-10-16 15:29:50 +0000 change file ownership in do_install() is not reflected in final rootfs 2013-10-18 13:35:53 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.5 Other arm RESOLVED INVALID Undecided normal --- 1 davide.soldan richard.purdie bluelightning poky.bs.watcher poky.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 37986 0 davide.soldan 2013-10-16 15:29:50 +0000 branch: dora commit id (meta-yocto): 56f39bcf2237c11508d82238b6292e4bfbfed764 (meta-fsl-arm): 00f0cf377224829f450d99bdc4664ffe96623996 (meta-fsl-arm-extra): 12af63db7719877fd191ed2aa921a455a04f677b (meta-fsl-demos): 393b0119d513f9abf7b0570ab0d32b81583dedca Hi, in my recipe I want to change owner and permission of a file, so I wrote: do_install() { ls -la ${D}/opt/user chown -R user ${D}/opt/user chgrp -R user ${D}/opt/user ls -la ${D}/opt/user chmod 754 ${D}/opt/user/user.sh ls -la ${D}/opt/user } the output of ls commands is: drwxr-xr-x 8 root root 4096 Oct 15 11:13 . drwxr-xr-x 3 root root 4096 Oct 15 11:13 .. -rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh drwxr-xr-x 8 user user 4096 Oct 15 11:13 . drwxr-xr-x 3 root root 4096 Oct 15 11:13 .. -rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh drwxr-xr-x 8 user user 4096 Oct 15 11:13 . drwxr-xr-x 3 root root 4096 Oct 15 11:13 .. *-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh So the change of owner and permission works fine in do_install phase. Opening the final rootfs tarball, however, the file user.sh has still 754 permission but root not user as owner... The only workaround found to change file ownership is to run a postinstall script at board boot: pkg_postinst_${PN}() { #!/bin/sh -e if [ x"$D" = "x" ]; then chown -R user /opt/user chgrp -R user /opt/user else exit 1 fi } 38035 1 bluelightning 2013-10-18 10:06:15 +0000 You haven't mentioned above how you're actually creating the "user" user. Assuming it's the same as in the mailing list thread, i.e. adding DEPENDS on another recipe which adds the user via useradd, as mentioned in my follow-up reply on the mailing list I don't think this is expected to work. Typically, recipes that need a specific user to exist use useradd.bbclass themselves rather than depending upon another recipe that does it. However, if you do need to do it in a separate recipe (e.g. because multiple recipes use the same user account), just adding the other recipe to DEPENDS wouldn't be the right thing to do because that won't guarantee that the user will exist at runtime - the actual package generated by the other recipe (usually the same name) would need to be added to RDEPENDS_${PN}. Even then though this may not currently work. 38043 2 bluelightning 2013-10-18 13:35:53 +0000 Marking resolved after discussion on the mailing list.