Python app ownership issue

Technical Support
, ,
4

Hi @fahads ,

thanks for your reply. is it targetfiles or targetcommands?

It should be targetfiles. One thing I forgot to mention is that this property should only be applied to release, as it breaks the debug build. You can check how to apply a property only to a specific type of build here: Systemd service management on Torizon - #17 by lucas_a.tx. However, I have a possible better solution than using this property, see below.

I’ve talked to the extension team and here’s what I got:

  • The /setup.sh debug and /cleanup.sh debug lines present on Dockerfile.release are indeed not intentional and should be corrected in a future update. Thank you for reporting this!

  • The difference in ownership is due to how the Docker image is built for each type:

    • On debug the project directory (in your case /file-write) is a bind mount; VSCode first copies it to your SoM (specifically to the $HOME directory) then runs the container with argument --volume. If the extension is accessing the SoM via SSH as torizon, then this user will be the owner of the folder.

    • On release the project directory is part of the Docker image as it is copied to the image when building it with docker build. Given that in Dockerfile.release the copy occurs before defining a user, the default owner is root.

With this difference in mind I’d recommend creating a new bind mount in volumes and write all your files there instead of using the app folder, as this alternative should work without problems on both debug and release builds. If you do this the owner of the bind mount will be torizon if the extension is accessing the SoM with this user, which is usually the case.

Let me know if this helps you.

Best regards,
Lucas Akira