Localstorage & /app/data

[BrutalBirdie]

/app/data is being created by the localstorage addon on runtime.

That's why many times in the Dockerfile we move folders/files to file_default and in the Dockerfile create a symlink to /app/data and then in the start script we copy the default to /app/data

[girish]

@timconsidine said in Localstorage & /app/data:

It seems that what I prepare in the Dockerfile in /app/data gets wiped when the app starts.

Right, as @BrutalBirdie said, you should not prepare /app/data in the Dockerfile. Instead, prepare it at runtime, in your start.sh. In the Dockerfile, copy the files you need into /app/code or /app/pkg or something. Then, in start.sh copy over files from /app/pkg into /app/data.

[timconsidine]

Thank you @BrutalBirdie and @girish

And symlinks ? Better to create in the Dockerfile ?

[girish]

@timconsidine I assume you mean symlinks from code to some writable data path? If so, yes, Dockerfile is the correct place.

[timconsidine]

@girish Thank you.
I seem to be stuck in a loop (although I am not 100% sure what's going on).
I create a symlink in the Dockerfile from a code directory to a writable data location.
In the start.sh I copy contents of code directory to the /app/data path.
But I'm using localstorage addon and I think it destroys the symlink when it creates /app/data.
But I can't create or recreate the symlink in start.sh (as /app/code is readonly).

in dockerfile :

RUN mv /app/code/data /app/code/datasrc \
    && mkdir -p /app/code/datasrc/uploads \
    && ln -s /app/data/data /app/code/data \
    && ln -s /app/data/public /app/code/public

in start.sh :

mkdir -p /app/data/public /app/data/data
cp -r /app/code/client/* /app/data/public/
cp -r /app/code/datasrc/* /app/data/data

App fails to launch because it tries to read (or write) to :
Error: EROFS: read-only file system, open '/app/code/public/flame.css'

But flame.css should be symlinked to /app/data/public/flame.css.

I'm too close to this to see the problem.
Any thoughts ?

[robi]

As was mentioned, you cannot do any /app/data operations in the Dockerfile.

[timconsidine]

@robi I don't think I am (now).

[timconsidine]

is /tmp writeable ?
e.g. can I prepare the app for runtime in /tmp, copy contents in start.sh and empty /tmp (for tidiness) ?

[nebulon]

/tmp is writeable and also created in runtime, however as the name suggests, the app should not rely on content to persist there. Traditionally it may be used as temporary storage for file uploads, of other caching files.

[robi]

@timconsidine said in Localstorage & /app/data:

@robi I don't think I am (now).

so what is this in Dockerfile?

&& ln -s /app/data/data /app/code/data \

&& ln -s /app/data/public /app/code/public

[timconsidine]

@robi that's from the start.sh file which runs after Dockerfile has been built to an image.

[robi]

@timconsidine I updated my post, since it's about the ln commands not the cp commands

[girish]

I would double check if the app was built and updated properly to use your latest Dockerfile. You can do cloudron debug and then you can cloudron exec to inspect if all the symlinks are proper. You can then launch your start.sh manually in that shell also.

[timconsidine]

Thank you
So app builds and launches, symlinks created in Dockerfile work
But there is weirdness in running start.sh
Some commands executed, some not.
Eg the first mkdir works but not #2 or #3
The first cp from tmp works but not #2 or #3
The chown doesn't work but the script is running to the end and working because the app launches.
Any ideas ?
Here's the start.sh :

#!/bin/bash
# set -eu
mkdir -p /app/data/config || true
mkdir -p /app/data/public || true
mkdir -p /app/data/images || true
cp -r /tmp/skeleton/* /app/data/config
cp -r /tmp/public/* /app/data/public 
cp -r /tmp/images/* /app/data/images 
chown -R cloudron:cloudron /app/data
export npm_config_cache=/app/data/.npm-cache
exec /usr/local/bin/gosu cloudron:cloudron npm start

Cloudronmanifest.json has localstorage addon and proxyAuth addon.

[nebulon]

@timconsidine not sure if this the main problem, but mkdir -p ... does "no error if existing, make parent directories as needed" so should run it without the || true also if essential commands don't work in start.sh the app should not just continue anways in some unknown state.

[timconsidine]

@nebulon thank you
I stuck in the || true because chatGPT told me to do so when I asked it why the script wasn't working !

Yep, it's weird behaviour, some lines working but some not.
I can execute the failed lines manually in Terminal, but not the right way to do it !

[BrutalBirdie]

@timconsidine said in Localstorage & /app/data:

I stuck in the || true because chatGPT told me to do so when I asked it why the script wasn't working !

lol - That will just always make an exec return true / successful even when it fails.

AI will replace developers right.

[timconsidine]

@BrutalBirdie said in Localstorage & /app/data:

AI will replace developers right.

Absolutely ... not !
I have seen some absolute shockers (hallucinations, wrong responses) but nevertheless I do find it useful.
Comes back to that old age truth : you can have the best sword/drill/hammer in the world, but it's only useful if you know how to use it.
AI is helpful ... except when it's not and you recognise it is not !

[robi]

If you stop calling it AI, it will begin to make sense as a tool.