How to set docRoot? #4

New issue

Griefed · 2026-06-23T17:58:18+02:00

Griefed commented

2026-06-23 17:58:18 +02:00

Created by: derekoharrow

Great image - works well!

I'm trying to figure out how to set the root for the IDE though. It seems to default to /app/ICEcoder. You can then set a subfolder of that as your root, but how do you change it from /app/ICEcoder to something else?

Thanks

> **@Griefed** on **GitLab** · https://git.griefed.de/Griefed/docker-ICEcoder/-/issues/2 *Created by: derekoharrow* Great image - works well! I'm trying to figure out how to set the root for the IDE though. It seems to default to /app/ICEcoder. You can then set a subfolder of that as your root, but how do you change it from /app/ICEcoder to something else? Thanks

Griefed closed this issue

2026-06-23 17:58:19 +02:00

Griefed commented

2026-06-23 17:58:19 +02:00

Yep, you're correct. I misinterpreted the way ICEcoder handles the file manager. The highest you can go with it is /app/ICEcoder. No wonder no directories or files show up when I set it to /griefed even though I've mounted a folder to said location and put a testfile in it. I honestly believed you could set the file manager to any directory. Huh.

So, the way I see it, there are two solutions to this, one of which is a workaround and not permanent.

1: Workaround, symlinking the mounted directory to /app/ICEcoder/, won't survive container recreation

Mount a volume to your desired directory e.g. path/on/host:/derekoharrow
Exec into the container using docker exec -it icecoder /bin/bash
Create a symlink from the directory to /app/ICEcoder ln -s /derekoharrow /app/ICEcoder/derekoharrow
Set the ICEcoder file manager to /derekoharrow

Files and directories will not be touched by the ownership and permission scripts which are executed when starting the container, but you will have access to your files in the directory.

2: Customize the image

Clone the repo
Create and edit root/etc/cont-init.d/61-config and add the following:

#!/usr/bin/with-contenv bash

ln -s /derekoharrow /app/ICEcoder/derekoharrow

Build the image with a mount set to :/derekoharrow
Set the ICEcoder file manager to /derekoharrow

The symlink now always exists but the files aren't touched be ownership or permission checks as inside /app/ICEcoder/derekoharrow is just a symlink and chown -R doesn't follow it, neither does chmod -R.

Would this help?

Cheers,
Griefed

> **@Griefed** on **GitLab** Yep, you're correct. I misinterpreted the way ICEcoder handles the file manager. The highest you can go with it is /app/ICEcoder. No wonder no directories or files show up when I set it to `/griefed` even though I've mounted a folder to said location and put a testfile in it. I honestly believed you could set the file manager to any directory. Huh. So, the way I see it, there are two solutions to this, one of which is a workaround and not permanent. ### 1: Workaround, symlinking the mounted directory to /app/ICEcoder/, won't survive container recreation 1. Mount a volume to your desired directory e.g. `path/on/host:/derekoharrow` 2. Exec into the container using `docker exec -it icecoder /bin/bash` 3. Create a symlink from the directory to /app/ICEcoder `ln -s /derekoharrow /app/ICEcoder/derekoharrow` 4. Set the ICEcoder file manager to `/derekoharrow` Files and directories will not be touched by the ownership and permission scripts which are executed when starting the container, but you will have access to your files in the directory. ### 2: Customize the image 1. Clone the repo 2. Create and edit `root/etc/cont-init.d/61-config` and add the following: ```bash #!/usr/bin/with-contenv bash ln -s /derekoharrow /app/ICEcoder/derekoharrow ``` 3. Build the image with a mount set to `:/derekoharrow` 4. Set the ICEcoder file manager to `/derekoharrow` The symlink now always exists but the files aren't touched be ownership or permission checks as inside /app/ICEcoder/derekoharrow is just a symlink and chown -R doesn't follow it, neither does chmod -R. Would this help? Cheers, Griefed

Griefed commented

2026-06-23 17:58:19 +02:00

Created by: derekoharrow

Thanks, but the setting of ownership causes me problems as it tries to set the owner on thousands of files, which can cause problems with other containers and takes ages to start up.

Ideally, I'd like to have another folder under there that I can mount for editing files. I suspect that would mean changing your startup scripts.

> **@Griefed** on **GitLab** *Created by: derekoharrow* Thanks, but the setting of ownership causes me problems as it tries to set the owner on thousands of files, which can cause problems with other containers and takes ages to start up. Ideally, I'd like to have another folder under there that I can mount for editing files. I suspect that would mean changing your startup scripts.

Griefed commented

2026-06-23 17:58:19 +02:00

I'll probably implement the suggestion as a change to the directory where the, if specified, git repo will be cloned to, the one specified with -e GITURL=https://github.com/icecoder/ICEcoder.git 👍

Glad I could help you out. 🙂 I'll close this issue. If you have further suggestions either reopen or create a new issue.

Stay safe and healthy, take care.
Cheers,
Griefed

> **@Griefed** on **GitLab** I'll probably implement the suggestion as a change to the directory where the, if specified, git repo will be cloned to, the one specified with `-e GITURL=https://github.com/icecoder/ICEcoder.git` 👍 Glad I could help you out. 🙂 I'll close this issue. If you have further suggestions either reopen or create a new issue. Stay safe and healthy, take care. Cheers, Griefed

Griefed commented

2026-06-23 17:58:20 +02:00

Created by: derekoharrow

I've tried this and while the mount point is visible within the container, it doesn't show up in ICEcoder at all as it's not under the docRoot /app/ICEcoder

> **@Griefed** on **GitLab** *Created by: derekoharrow* > In that case, you could try mounting a volume like `path/to/derekoharrow:/derekoharrow`, set the permissions and ownership once and use that folder going forward. Since it's mounted, it's not lost when recreating the container and as it's not touched by the container configuration, it doesn't impact startup time. I've tried this and while the mount point is visible within the container, it doesn't show up in ICEcoder at all as it's not under the docRoot /app/ICEcoder

Griefed commented

2026-06-23 17:58:20 +02:00

In that case, you could try mounting a volume like path/to/derekoharrow:/derekoharrow, set the permissions and ownership once and use that folder going forward. Since it's mounted, it's not lost when recreating the container and as it's not touched by the container configuration, it doesn't impact startup time.

> **@Griefed** on **GitLab** In that case, you could try mounting a volume like `path/to/derekoharrow:/derekoharrow`, set the permissions and ownership once and use that folder going forward. Since it's mounted, it's not lost when recreating the container and as it's not touched by the container configuration, it doesn't impact startup time.

Griefed commented

2026-06-23 17:58:20 +02:00

Finally got around to implement, test, push etc. etc. your suggestion! 🙂
It's now available via the latest-tag. I've changed the way the /code directory is handled and it can now be safely used as your file manager root directory. It shouldn't slow down container start anymore as the permission passes don't affect it during container start.
Let me know if anything else pops up!

Cheers,
Griefed

> **@Griefed** on **GitLab** Finally got around to implement, test, push etc. etc. your suggestion! 🙂 It's now available via the `latest`-tag. I've changed the way the `/code` directory is handled and it can now be safely used as your file manager root directory. It shouldn't slow down container start anymore as the permission passes don't affect it during container start. Let me know if anything else pops up! Cheers, Griefed

Griefed commented

2026-06-23 17:58:20 +02:00

Hey there derekoharrow,

thanks for your question. 🙂
I've just tested it with the /code directory, which is not a subfolder of /app/ICEcoder and it seems to work just fine.

So, if I understand you correctly, you don't need to specify a subfolder of ICEcoder, but can instead choose any directory in the container. That directory should be either one of the directories specified in the deployment section, or a subfolder of these. The reason for that being that these directories have their permissions and ownership set everytime the container starts, ensuring file access between host and container.

That being said, you could set your file manager root to /code/derekoharrow as an example. Note: Testing showed that you need to create the directory either via CLI or in ICEcoder, otherwise the right-click context menu won't work for some strange reason, and therefor not allow you to create files.

Hope this helps.

Cheers,
Griefed

> **@Griefed** on **GitLab** Hey there derekoharrow, thanks for your question. 🙂 I've just tested it with the /code directory, which is not a subfolder of /app/ICEcoder and it seems to work just fine. ![image](https://user-images.githubusercontent.com/44273438/103238754-ed725500-494b-11eb-813c-c2d0f4200aa6.png) So, if I understand you correctly, you don't need to specify a subfolder of ICEcoder, but can instead choose any directory in the container. That directory should be either one of the directories specified in the deployment section, or a subfolder of these. The reason for that being that these directories have their permissions and ownership set everytime the container starts, ensuring file access between host and container. That being said, you could set your file manager root to `/code/derekoharrow` as an example. Note: Testing showed that you need to create the directory either via CLI or in ICEcoder, otherwise the right-click context menu won't work for some strange reason, and therefor not allow you to create files. ![image](https://user-images.githubusercontent.com/44273438/103239293-60c89680-494d-11eb-85fa-2de062d89c2f.png) Hope this helps. Cheers, Griefed

Griefed commented

2026-06-23 17:58:21 +02:00

Created by: derekoharrow

Thanks for coming back to me.

(1) definitely works and I can use this temporarily.

Could I suggest that you update your image for (2) - perhaps adding a mount point of /src which could then be linked as you suggest?

I don't mind copying and modifying your image, but it sounds like a useful improvement to yours that others could benefit from too.

Thanks for your help!

> **@Griefed** on **GitLab** *Created by: derekoharrow* Thanks for coming back to me. (1) definitely works and I can use this temporarily. Could I suggest that you update your image for (2) - perhaps adding a mount point of /src which could then be linked as you suggest? I don't mind copying and modifying your image, but it sounds like a useful improvement to yours that others could benefit from too. Thanks for your help!

Sign in to join this conversation.