Application folder is write protected when deploy release container

Hello.
We have a dotnet application which needs to save some data in application folder.
When debug container deployed, application folder is located at /home/torizon/App. This folder is not write protected and application can create and write data files here. But when deploy the release container, application folder is located at:
/var/lib/docker/overlay2/9d7e7c23fe6a2a3a9110602d6d6b0701741d5c34a8387753fc3459a8abff98f7/diff/App. This folder is a read only, so application provides an exception when trying to write there. If changing the permissions to 777 for /var/lib/docker/overlay2 folder application can start and works fine, but here we have a secure problem and cannot leave it like that. Is it any way to fix this issue, so App folder will be writable after the release container deployed?
Thanks.

Greetings @Serghey,

Just to make sure I understand your situation I have a few questions.

  • It sounds like you’re using our VSCode extension to develop your .NET application is that correct?
  • If yes then what version of the extension are you using, the stable or early access version?
  • To set your application folder in the extension are you using the volumes configuration option in the extension? If yes, then what have you set this option to?
  • Finally, your use-case here, do you want this application folder inside or outside of the container?

Based off the information you gave it sounds like you might be a little confused about how the extension works. For debugging purposes the extension will create a /home/torizon/<application name> folder with your application related files to help debug. However for release this is obviously not needed therefore this folder only exists in the container. The /var/lib/docker/overlay section is a overlay file system representation of the container filesystem. You really should not be modifying this from outside of the container.

Best Regards,
Jeremias

Hello Jeremias.
We use VSCode with early access 1.4.265 extension. the template is dotnet/uno.
I believe we did not do anything with volumes configuration and use the default template settings.
We want this application folder in area where write access is enable (probably at /home/torizon?)
Will appreciate if you direct which file needs to be modified and what changes should be done.
Thank you.

Just to clarify, you can do two things here. You can write your application data inside the container or outside of the container. Data written inside the container only exists as long as that container runs. Meaning if the container goes away so does the data. If you write the data outside of the container then it will persist even if the container goes away.

It sounds like you want to write the data outside of the container in /home/torizon. To do this you need to configure the container such that it bind mounts a location outside of the container into the container. In the extension this is what the volumes configuration option is for. We have a little guide here on how to do this: Torizon Best Practices Guide

Best Regards,
Jeremias

We already tried to add the volume. Unfortunately looks like there is some bug in Torizon extension we use. It immediately provides the following message: “Value cannot be empty string” (white with the red background, and does not let to create the volume. I believe it could be added manually to config.yaml, but do not know the syntax . Do you have some example for config.yaml with volume mounted?
Now we have there:
volumes:
common: {}
debug:
/home/torizon/App: /App,rw
release: {}

“Value cannot be empty string” (white with the red background, and does not let to create the volume.

Weird I was able to reproduce this bug as well. Seems to be a new bug. As for manually editing the config.yaml, I wouldn’t recommend this. The config.yaml gets auto-generated based off the of the project’s configuration. Meaning your manual changes will get overwritten as the file gets auto-generated.

Let me report this to the IDE team and hopefully it’s a quick and simple bug to fix.

Best Regards,
Jeremias

@Serghey, actually wait ignore my above message, I think we’re both mistaken. This isn’t a bug but rather VSCode has changed it’s UI a bit. So for the volumes configuration you need to enter both a key and value pair. Before there was separate prompts to enter the key then the value, as shown in the video from our article. But now it seems like it’s the same prompt. Notice the picture below, in the top right hand corner I marked with a black rectangle. What you need to do is enter something for the key the click on the abc and you can type the path for the value. Then you can hit enter

Best Regards,
Jeremias

Thank you, it works. When container starts it creates data storage folder at /home/torizon/. (the folder name is slpdata). But application cannot write to this folder and gives an exception:
System.UnauthorizedAccessException: Access to the path ‘/slpdata/device.serial’ is denied.
When we change this folder permission to 777 from the console, application starts as expected. Looks like container by default does not have a permission to write this folder?

Okay wait what is creating the slpdata directory? Is it the application code? Or are you creating it yourself on the command-line then bind-mounting it in?

Whatever is creating the slpdata directory should set the permissions at that time. What is your exact bindmount? Are you bindmounting in /home/torizon/slpdata into the container?

Best Regards,
Jeremias

It created after I added the volume with the key /home/torizon/slpdata and /slpdata value.
Then when I trying to write into it it provides the exception.

You should be making the slpdata directory yourself manually outside of the container, before running the container that way you can set the permissions on that directory. Then when the directory gets bind-mounted into the container it should retain the permissions.

Best Regards,
Jeremias

Thank you,
this is what we did:

  1. Create slpdata folder with write permissions. It created by service which running the following script:
    #!/bin/bash
    if [ -d “/var/rootdirs/home/torizon/slpdata” ]
    then
    echo “Folder already exists”
    else
    mkdir /home/torizon/slpdata
    chmod -R 777 /home/torizon/slpdata
    fi
    Now folder is created and we can launch application container when deploy and run it from Visual studio code. app can write data to slpdata folder.
    But when we create the customized deployment package, container cannot run. Data folder (slpdata) created but application is not start. What is the difference when image deployed from VS Code and from the package created by TorizoneCore builder?

What is the command/docker-compose file you are using to launch your container? It sounds like you’re not starting your container correctly compared to when it’s deployed from VSCode.

Best Regards,
Jeremias

When I remove operator from application which trying to write into slpdata folder container starts normally.
So when start the release container from VS Code it can write into slpdata folder, when start it after production deployment application still has no permission to write.

Sorry Jeremias,
please ignore the previous message. I had old docker compose opened and accidently saved it as a new one. now everything works perfectly, application can save data outside of the container.
Thank you very much for your help.
Best regards,
Serghey.

Ahh okay glad we were able to clear up the misunderstanding, glad to have assisted you.

Best Regards,
Jeremias