And now the app is broken after latest Manjaro Pahvlo update

[neurodiverseEsoteric]

This happens whenever I try to login by pin/recovery key/password:

DatabaseError [SequelizeDatabaseError]: SQLITE_NOTADB: file is not a database
    at Query.formatError (/tmp/.mount_CripteLcb5JF/resources/app.asar/node_modules/sequelize/lib/dialects/sqlite/query.js:422:16)
    at Query._handleQueryResponse (/tmp/.mount_CripteLcb5JF/resources/app.asar/node_modules/sequelize/lib/dialects/sqlite/query.js:73:18)
    at afterExecute (/tmp/.mount_CripteLcb5JF/resources/app.asar/node_modules/sequelize/lib/dialects/sqlite/query.js:250:31)
    at replacement (/tmp/.mount_CripteLcb5JF/resources/app.asar/node_modules/@journeyapps/sqlcipher/lib/trace.js:19:31)
    at Statement.errBack (/tmp/.mount_CripteLcb5JF/resources/app.asar/node_modules/@journeyapps/sqlcipher/lib/sqlite3.js:16:21) {
  name: 'SequelizeDatabaseError',
  parent: [Error: SQLITE_NOTADB: file is not a database] {
    errno: 26,
    code: 'SQLITE_NOTADB',
    sql: 'SELECT * from account'
  },
  original: [Error: SQLITE_NOTADB: file is not a database] {
    errno: 26,
    code: 'SQLITE_NOTADB',
    sql: 'SELECT * from account'
  },
  sql: 'SELECT * from account',
  parameters: undefined
}

[thebiblelover7]

Same problem here

[neurodiverseEsoteric]

Same problem here

Well for now there's a workaround that's just to downgrade GTK3.0...

[namaenonaimumei]

@neurodiverseEsoteric Here is roughly containerized version for latest .AppImage you could try - requires docker and docker-compose, built container ~1GB, about as secure as hosting GUI apps with docker gets.

To setup, extract archive into directory and at docker-compose.yml:line 16 update first path to point at copy of Criptext-latest.AppImage (default /opt/criptext/Criptext-latest.AppImage) and run criptext_container as script.

Tested with Void/Gentoo/Arch, but should work as long as you can use X server forwarding and docker daemon.

[neurodiverseEsoteric]

@neurodiverseEsoteric Here is roughly containerized version for latest .AppImage you could try - requires docker and docker-compose, built container ~1GB, about as secure as hosting GUI apps with docker gets.

To setup, extract archive into directory and at docker-compose.yml:line 16 update first path to point at copy of Criptext-latest.AppImage (default /opt/criptext/Criptext-latest.AppImage) and run criptext_container as script.

Tested with Void/Gentoo/Arch, but should work as long as you can use X server forwarding and docker deamon.

Sounds a bit much for such a light application, and it assumes I know how to use docker and/or forward X servers

[neurodiverseEsoteric]

@neurodiverseEsoteric Here is roughly containerized version for latest .AppImage you could try - requires docker and docker-compose, built container ~1GB, about as secure as hosting GUI apps with docker gets.

To setup, extract archive into directory and at docker-compose.yml:line 16 update first path to point at copy of Criptext-latest.AppImage (default /opt/criptext/Criptext-latest.AppImage) and run criptext_container as script.

Tested with Void/Gentoo/Arch, but should work as long as you can use X server forwarding and docker deamon.

It also doesn't work because of file permission errors

[namaenonaimumei]

It should work granted you are part of docker group and criptext_container and Criptext-latest.AppImage have executable permission, in my case /opt/criptext directory itself was owned by user as well, since I have it as user-wide installation. If that doesn't help, I at least need docker log output from when you run criptext_container to help you figure it out.

As for first comment, you are right about this solution being overkill for average user, but I would say it's still better than setting separate VM just for mail client, which would be the other feasible way right now (if you can't afford to have your whole system version frozen). I just made that script as temporary solution - if there won't be any updates, I may into this some more, when I have time.

As for X server forward/docker knowledge you don't need to do anything extra as long as you have installed docker and docker-compose packages - that was just a note for more exotic setups (and possible wayland issues, though I didn't get any testing).

[neurodiverseEsoteric]

I think chmodding anything in /opt/ would break manjaro, especially with sudo

[neurodiverseEsoteric]

I also probably need to delete the container to show you what happens with your original script(s), since I tried re-naming directories and usernames in those files in hopes that it would fix the permissions issues....

[neurodiverseEsoteric]

@namaenonaimumei Okay I didn't reinstall docker or the original container, but I did try to run a vanilla version of your code. Here's what happened:

Sending build context to Docker daemon  1.244kB
Step 1/14 : FROM ubuntu:20.04
 ---> ba6acccedd29
Step 2/14 : RUN apt-get update
 ---> Using cache
 ---> 203f6aa65aa4
Step 3/14 : RUN apt-get install -y fonts-noto locales
 ---> Using cache
 ---> 3f7e10c532ae
Step 4/14 : RUN apt-get install -y libx11-xcb-dev dbus-x11 xauth
 ---> Using cache
 ---> 13d8d2ab956f
Step 5/14 : RUN apt-get install -y libnss3 libsecret-1-0 gnome-keyring
 ---> Using cache
 ---> 531ae4aa0bba
Step 6/14 : RUN apt-get install -y libasound2
 ---> Using cache
 ---> 641046cf359d
Step 7/14 : RUN locale-gen --no-purge ${LANG}
 ---> Using cache
 ---> 07bda435ae18
Step 8/14 : COPY docker_ep.sh /opt/criptext/ep
 ---> Using cache
 ---> fa8146f18327
Step 9/14 : RUN chmod 555 /opt/criptext/ep
 ---> Using cache
 ---> 068f162aca16
Step 10/14 : RUN groupadd -g 1000 arbitrator
 ---> Using cache
 ---> 0eaaa07a9401
Step 11/14 : RUN useradd -d /home/arbitrator -s /bin/bash -m arbitrator -u 1000 -g 1000
 ---> Using cache
 ---> 7ab8c8f915f7
Step 12/14 : USER arbitrator
 ---> Using cache
 ---> 42ba4d49d3ae
Step 13/14 : ENV HOME /home/arbitrator
 ---> Using cache
 ---> f76ee5d85961
Step 14/14 : ENTRYPOINT ["/opt/criptext/ep"]
 ---> Using cache
 ---> 8a70f190ca3d
Successfully built 8a70f190ca3d
Successfully tagged criptext:latest
non-network local connections being added to access control list
[+] Running 1/0
 ⠿ Container criptext-react-latest  Created                                                                                                                                                                                                                                                                                                                                                                                                                                           0.0s
Attaching to criptext-react-latest
Error response from daemon: failed to create shim: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/opt/criptext/Criptext-latest.AppImage" to rootfs at "/opt/criptext/Criptext.AppImage": mount /opt/criptext/Criptext-latest.AppImage:/opt/criptext/Criptext.AppImage (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
non-network local connections being removed from access control list

And that is with both Criptext-latest.AppImage and Criptext.AppImage (same file basically) copied to /opt/criptext with /opt/criptext having chmod a+rx permissions...

[namaenonaimumei]

@neurodiverseEsoteric

Error response from daemon: failed to create shim: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/opt/criptext/Criptext-latest.AppImage" to rootfs at "/opt/criptext/Criptext.AppImage": mount /opt/criptext/Criptext-latest.AppImage:/opt/criptext/Criptext.AppImage (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

To replicate your error criptext appimage path would have to be detected as a directory by docker (either on host or container side). For permissions try stat /opt/criptext/Criptext-latest.AppImage - output permissions should be something like this -rwxr-xr-x:$USER:$USER, for /opt/criptext/ drwxr-xr-x:$USER:$USER, but they are probably fine already (both can be owned by root uid/gid either).

To me it looks like when you first run ./criptext_container, /opt/criptext/Criptext-latest.AppImage didn't exist and since docker creates directories for non-existing paths as it mounts them, it first mounted as such (creating directories /opt/criptext/Criptext-latest.AppImage/ at host and /opt/criptext/Criptext.AppImage/ at container ends) and now that /opt/criptext/Criptext-latest.AppImage is a file it tries to mount it as such and fails (since inside built container /opt/criptext/Criptext.AppImage is a directory).

To fix you could try (for vanilla version as provided)

docker container ls -as # lists all built containers
docker rm $CONTAINER_ID # removes container, $CONTAINER_ID being CONTAINER ID from command above for NAME "criptext-react-latest"
# make sure `/opt/criptext/Criptext-latest.AppImage` is valid path to criptext appimage file here
./criptext_container # Start main script unpacked from criptext-container.tar.gz which will build and then launch new container

Also note you can chmod single subdirectories you created yourself inside /opt like /opt/criptext, it's just you shouldn't alter /opt permissions or whichever subdirectory pacman etc. creates there. Path /opt/criptext/Criptext.AppImage is file as it is inside docker container itself - it doesn't have to exist on your host.

Sorry for late answer as well - somehow missed notification before.

[neurodiverseEsoteric]

Thanks for getting back to me. I appear to have a ton of containers for reasons I can't recall or that which are completely unknown to me... Should I get rid of all of them, just in case:

CONTAINER ID   IMAGE             COMMAND                  CREATED        STATUS                     PORTS     NAMES                   SIZE
fc511e714229   criptext:latest   "/opt/criptext/ep"       5 weeks ago    Exited (127) 5 weeks ago             criptext-react-latest   776B (virtual 1.08GB)
13699b4774ae   00cd859092e7      "/home/tbd/ /bin/sh …"   3 months ago   Created                              clever_curran           0B (virtual 1.2GB)
7b9933d4baaf   00cd859092e7      "/opt/criptext/ep /b…"   3 months ago   Created                              eloquent_moore          0B (virtual 1.2GB)
539eef3d3e4c   40cb4c009ce9      "/bin/sh -c '#(nop) …"   3 months ago   Created                              vigorous_jones          0B (virtual 1.2GB)
afe1cdfc28cb   6e967b736d84      "/bin/sh -c '#(nop) …"   3 months ago   Created                              silly_bartik            0B (virtual 1.2GB)
0280f82d5a1f   658744e26e0f      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              nostalgic_haslett       328kB (virtual 1.2GB)
8a0c18275743   74197e307a96      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              modest_kilby            2.07kB (virtual 1.2GB)
ce5911da06b3   9e3374690fdd      "/opt/criptext/ep /b…"   3 months ago   Created                              relaxed_shamir          0B (virtual 1.2GB)
49de3a4cc86a   6db456983ffb      "/bin/sh -c '#(nop) …"   3 months ago   Created                              charming_lamport        0B (virtual 1.2GB)
38b9e949e1a5   3888d6b95f28      "/bin/sh -c '#(nop) …"   3 months ago   Created                              gracious_feynman        0B (virtual 1.2GB)
68ab57958719   d553da9bd9ef      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              cranky_bassi            328kB (virtual 1.2GB)
02680f55b79b   8b26793cf1b2      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              vibrant_clarke          2.07kB (virtual 1.2GB)
bc5f2020822c   fe837ef0821a      "/opt/criptext/ep /b…"   3 months ago   Created                              blissful_engelbart      0B (virtual 1.2GB)
ed5182ca5cfc   9051e0f49604      "/bin/sh -c '#(nop) …"   3 months ago   Created                              zealous_nash            0B (virtual 1.2GB)
36ce60d0e719   e41f23cef88f      "/bin/sh -c '#(nop) …"   3 months ago   Created                              ecstatic_kowalevski     0B (virtual 1.2GB)
9349c1f67354   fff1c4171d35      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              zealous_wu              332kB (virtual 1.2GB)
b5d67b83a95b   94622445a982      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              elegant_hellman         2.07kB (virtual 1.2GB)
ea160e07dd80   6a57b55ed4f5      "/opt/criptext/ep /b…"   3 months ago   Created                              intelligent_hoover      0B (virtual 1.2GB)
d6e55b7b1cd6   4a45a90033df      "/bin/sh -c '#(nop) …"   3 months ago   Created                              fervent_northcutt       0B (virtual 1.2GB)
82acb39bed05   97edd02ec5a2      "/bin/sh -c '#(nop) …"   3 months ago   Created                              suspicious_bardeen      0B (virtual 1.2GB)
2cb492b2b022   010e8ccc8f14      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              gifted_driscoll         332kB (virtual 1.2GB)
0bb3f05ac130   02540a3c70e0      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              silly_engelbart         2.07kB (virtual 1.2GB)
7484a0e42bc2   de1f3467dadf      "/opt/criptext/ep /b…"   3 months ago   Created                              zen_ritchie             0B (virtual 1.08GB)
03cb3cf37ffe   573111c0b4b5      "/bin/sh -c '#(nop) …"   3 months ago   Created                              awesome_chebyshev       0B (virtual 1.08GB)
6672e536f5d9   fada8e05da22      "/bin/sh -c '#(nop) …"   3 months ago   Created                              nervous_kapitsa         0B (virtual 1.08GB)
6a10e591ea4d   5bd960d9d766      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              elegant_ellis           332kB (virtual 1.08GB)
ee047bafceb8   942f8c414d72      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              compassionate_lalande   2.07kB (virtual 1.08GB)
917cbe8bd8e5   733171020907      "/opt/criptext/ep /b…"   3 months ago   Created                              vibrant_lamport         0B (virtual 1.08GB)
fe312d9fc006   2a5b2db4bdb7      "/bin/sh -c '#(nop) …"   3 months ago   Created                              cranky_margulis         0B (virtual 1.08GB)
473a9adfd13c   8ea7fa14cbff      "/bin/sh -c '#(nop) …"   3 months ago   Created                              elastic_jemison         0B (virtual 1.08GB)
671fb078bbfc   fc9671362425      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              fervent_jemison         332kB (virtual 1.08GB)
4a140b7e6eb9   942f8c414d72      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              heuristic_dhawan        2.09kB (virtual 1.08GB)
f8646688d9e6   025b4d100303      "/bin/sh -c 'chmod 5…"   3 months ago   Exited (0) 3 months ago              interesting_noether     571B (virtual 1.08GB)
d9f0778fd0d8   b024ef02f34d      "/opt/criptext/ep /b…"   3 months ago   Created                              quirky_kalam            0B (virtual 1.08GB)
cc663df78702   efb28727f3f8      "/bin/sh -c '#(nop) …"   3 months ago   Created                              practical_shockley      0B (virtual 1.08GB)
77130ff57515   2f9adb8f6140      "/bin/sh -c '#(nop) …"   3 months ago   Created                              unruffled_lehmann       0B (virtual 1.08GB)
ba2d3a794123   7578ceb42524      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              keen_liskov             332kB (virtual 1.08GB)
50f68c287d03   b372efa53637      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              sweet_ishizaka          2.09kB (virtual 1.08GB)
e7fa037394ac   f972708d660a      "/bin/sh -c 'chmod 5…"   3 months ago   Exited (0) 3 months ago              festive_dhawan          571B (virtual 1.08GB)
c24ca69969c2   f76ee5d85961      "/opt/criptext/ep /b…"   3 months ago   Created                              gallant_germain         0B (virtual 1.08GB)
69ccd122753c   42ba4d49d3ae      "/bin/sh -c '#(nop) …"   3 months ago   Created                              cranky_newton           0B (virtual 1.08GB)
aadcada88687   7ab8c8f915f7      "/bin/sh -c '#(nop) …"   3 months ago   Created                              cranky_saha             0B (virtual 1.08GB)
aeb238e1b28b   0eaaa07a9401      "/bin/sh -c 'useradd…"   3 months ago   Exited (0) 3 months ago              suspicious_euclid       332kB (virtual 1.08GB)
baaa7ac44612   068f162aca16      "/bin/sh -c 'groupad…"   3 months ago   Exited (0) 3 months ago              happy_grothendieck      2.09kB (virtual 1.08GB)
f42d8dc73cc9   fa8146f18327      "/bin/sh -c 'chmod 5…"   3 months ago   Exited (0) 3 months ago              intelligent_booth       555B (virtual 1.08GB)
b1dc83e2a9ff   641046cf359d      "/bin/sh -c 'locale-…"   3 months ago   Exited (0) 3 months ago              fervent_curie           0B (virtual 1.08GB)
8c83c03f2fc5   531ae4aa0bba      "/bin/sh -c 'apt-get…"   3 months ago   Exited (0) 3 months ago              lucid_margulis          2.66MB (virtual 1.08GB)
20f365152e01   13d8d2ab956f      "/bin/sh -c 'apt-get…"   3 months ago   Exited (0) 3 months ago              laughing_lichterman     189MB (virtual 1.08GB)
07afd3d106db   3f7e10c532ae      "/bin/sh -c 'apt-get…"   3 months ago   Exited (0) 3 months ago              beautiful_lumiere       10.1MB (virtual 887MB)
9ced4d9ee574   203f6aa65aa4      "/bin/sh -c 'apt-get…"   3 months ago   Exited (0) 3 months ago              objective_swirles       772MB (virtual 877MB)
649dccd1756f   ba6acccedd29      "/bin/sh -c 'apt-get…"   3 months ago   Exited (0) 3 months ago              silly_buck              32MB (virtual 105MB)

[namaenonaimumei]

Other than fc511e714229 you don't have to remove anything else to test solution above. Although from log you sent, they all seem like attempts at trying to fix issues with criptext container, so it should be fine to remove ones with default generated name (random 2 word name ones ex. clever_curran), so ones from around 3 months ago.

If you don't use any docker images/containers yourself, you can mass remove them and cleanup docker in one go with (this will remove all containers that aren't currently running and old/unused images)

docker system prune

If log you sent shows entire output of docker container ls -as you should be fine running prune command above. Else you may remove multiple specific ones by hand with docker rm <CONTAINER_ID1> <CONTAINER_ID2>.....

[neurodiverseEsoteric]

Sadly still NG:

./criptext_container
Sending build context to Docker daemon  1.244kB
Step 1/14 : FROM ubuntu:20.04
 ---> ba6acccedd29
Step 2/14 : RUN apt-get update
 ---> Using cache
 ---> 203f6aa65aa4
Step 3/14 : RUN apt-get install -y fonts-noto locales
 ---> Using cache
 ---> 3f7e10c532ae
Step 4/14 : RUN apt-get install -y libx11-xcb-dev dbus-x11 xauth
 ---> Using cache
 ---> 13d8d2ab956f
Step 5/14 : RUN apt-get install -y libnss3 libsecret-1-0 gnome-keyring
 ---> Using cache
 ---> 531ae4aa0bba
Step 6/14 : RUN apt-get install -y libasound2
 ---> Using cache
 ---> 641046cf359d
Step 7/14 : RUN locale-gen --no-purge ${LANG}
 ---> Using cache
 ---> 07bda435ae18
Step 8/14 : COPY docker_ep.sh /opt/criptext/ep
 ---> Using cache
 ---> fa8146f18327
Step 9/14 : RUN chmod 555 /opt/criptext/ep
 ---> Using cache
 ---> 068f162aca16
Step 10/14 : RUN groupadd -g 1000 arbitrator
 ---> Using cache
 ---> 0eaaa07a9401
Step 11/14 : RUN useradd -d /home/arbitrator -s /bin/bash -m arbitrator -u 1000 -g 1000
 ---> Using cache
 ---> 7ab8c8f915f7
Step 12/14 : USER arbitrator
 ---> Using cache
 ---> 42ba4d49d3ae
Step 13/14 : ENV HOME /home/arbitrator
 ---> Using cache
 ---> f76ee5d85961
Step 14/14 : ENTRYPOINT ["/opt/criptext/ep"]
 ---> Using cache
 ---> 8a70f190ca3d
Successfully built 8a70f190ca3d
Successfully tagged criptext:latest
non-network local connections being added to access control list
[+] Running 1/0
 ⠿ Container criptext-react-latest  Created                                                                                                                                                                                                                                                                           0.0s
Attaching to criptext-react-latest
criptext-react-latest  | /opt/criptext/ep: line 16: /opt/criptext/Criptext.AppImage: No such file or directory
criptext-react-latest exited with code 127
non-network local connections being removed from access control list

[namaenonaimumei]

I can't really replicate this one, but it seems like /opt/criptext/Criptext.AppImage is not created (inside container). Are you sure that you use unmodified version of files, namely this line of docker-compose.yml is there (note case-sensitive file paths)

      - /opt/criptext/Criptext-latest.AppImage:/opt/criptext/Criptext.AppImage # adjust Criptext-latest.AppImage path by updating VAL1 in VAL1:VAL2

If that's right and it still happens, there may be some issues with previous docker image cache or some mounting permissions inside container. Here are few things you could try.

---

Try removing container again (as in docker rm $CONTAINER_ID) and run this once in same directory as criptext_container so something like

cd /path/to/criptext_container/directory
docker compose build --no-cache # rebuilds from scratch in case of cache issues
./criptext_container # runs criptext (won't build twice)

---

If it's still the same, first check whether this version makes a difference, again for first time run (remember to cd to separate dir you unpacked archive to)

cd /path/to/criptext_container/directory
docker compose build --no-cache
./criptext_container

This loosens permissions inside container itself, if it's some kind of silent mount failure.

---

If above still does nothing try this version, applying same setup steps as above. This fetches Criptext appimage directly into container instead reusing your appimage and will most definitely work.

[neurodiverseEsoteric]

~~I tried changing both VAR1 and VAR2 and the same thing did keep happening. And now that I've docker system prune --all'd, I can't get it to rebuild again:~~

docker compose build --no-cache
Sending build context to Docker daemon  1.246kB
Step 1/14 : FROM ubuntu:20.04
20.04: Pulling from library/ubuntu
4d32b49e2995: Pull complete 
Digest: sha256:bea6d19168bbfd6af8d77c2cc3c572114eb5d113e6f422573c93cb605a0e2ffb
Status: Downloaded newer image for ubuntu:20.04
 ---> ff0fea8310f3
Step 2/14 : RUN apt-get update
 ---> Running in b44975365e01
Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:2 http://security.ubuntu.com/ubuntu focal-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-updates/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-backports/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal-security/InRelease  Temporary failure resolving 'security.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.
Removing intermediate container b44975365e01
 ---> 759721dc5c05
Step 3/14 : RUN apt-get install -y fonts-noto locales
 ---> Running in d0f40e34232a
Reading package lists...
Building dependency tree...
Reading state information...
Package locales is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Unable to locate package fonts-noto
E: Package 'locales' has no installation candidate
1 error occurred:
        * Status: The command '/bin/sh -c apt-get install -y fonts-noto locales' returned a non-zero code: 100, Code: 100

Never mind, it was a VPN's fault

[namaenonaimumei]

Did any solution work after that or does it still error somewhere down the way - as mentioned, last solution should work if all the others would be to fail, unless docker itself is misconfigured in some way. Though in your case I think it's some resilient cache that caused these issues (which should be resolved by now, looking at your reply).

Also don't change VAL2 inside docker-compose.yml since that only alters path inside container and will require adjusting docker_ep.sh+clean container rebuild - this file won't be created at your actual /opt/criptext anyway, so don't bother changing it. For example if you set line in question to example below, /opt/criptext directory won't even have to exist on your filesystem - only /home/user/.local/share/criptext/Criptext-latest.AppImage will be used

      - /home/user/.local/share/criptext/Criptext-latest.AppImage:/opt/criptext/Criptext.AppImage

Try making it launch with default configs first though (if your container still fails build/launch).

[neurodiverseEsoteric]

Okay, looked into accessing Docker and tried that and it shows that the dir/file /opt/Criptext/Criptext.AppImage DOES exist (can spew out the binary via cat), but for some reason the container can't execute it...I suspect it's the base OS itself not being capable or too barebones/slimmed out...is there a way to use a more fleshed out version like ubuntu KDE or something?

[namaenonaimumei]

I suspect it's the base OS itself not being capable or too barebones/slimmed out...is there a way to use a more fleshed out version like ubuntu KDE or something?

Not really sure what you mean by this, but docker container works independently from system dependencies - that means you don't really have to worry about your system being "too minimalistic". You can think of each container you create as a separate machine (which in case of this container uses Ubuntu 20.04 as a base) that has limited access to your machine. Also container won't be able to execute/see /opt/criptext/Criptext.AppImage that exists directly on your system - it has to exist inside container itself (that's what that line in question from docker-compose.yml is about, VAL2 being "virtual" path inside container).

As for requirements, to run these containers all you need is system capable of running docker daemon + working network + X11 server (wayland should work, but may not out of box) - from what I understand you are using manjaro, which is more than enough to satisfy these requirements, granted you installed docker through package manager (pamac/pacman). Other than that all dependencies should have been pulled already - just in case you can send output of LC_ALL=C pacman -Qi docker.

---

/opt/Criptext/Criptext.AppImage DOES exist

I don't know whether you just mistyped path in reply above, but remember most things in unix are case-sensitive (including paths, meaning ../Criptext/!=../criptext/ etc.), which - when mismatched - can cause issues you described.

That being said, did you already try last resort version (criptext-container_fix02.tar.gz), since that version - as long as you run it with steps written above - will download criptext binary directly inside container. If you did and it still somehow fails, send log of that (rebuilt with docker compose build --no-cache).

I can't really tell for sure without seeing your exact system configuration, but from all logs/replies it seems you have issue with paths not being valid (on host, for container as long as you keep doing docker rm CONTAINER_ID; docker compose build --no-cache every try is in short like replacing separate machine with a new one) combined with docker reusing previous broken containers before. Only other thing I can think of at the moment docker itself could complain about, is /opt/criptext (note criptext lowercase) residing on something like NTFS (or dir having different permission than drwxr-xr-x) .

[neurodiverseEsoteric]

Sorry I was super drowsy when I wrote all that. Here's what I tried:

docker run --privileged -ti --user 1000 --entrypoint=bash criptext_f_02
arbitrator@7291cf71b560:/$ ls /opt
criptext
arbitrator@7291cf71b560:/$ ls /opt/criptext
Criptext.AppImage  ep
arbitrator@7291cf71b560:/$ /opt/criptext/Criptext.AppImage
bash: /opt/criptext/Criptext.AppImage: No such file or directory
arbitrator@7291cf71b560:/$ /opt/criptext/ep
/opt/criptext/ep: line 17: /opt/criptext/Criptext.AppImage: No such file or directory
arbitrator@7291cf71b560:/$ cat /opt/criptext/Criptext.AppImage | less
bash: less: command not found
arbitrator@7291cf71b560:/$ cat /opt/criptext/Criptext.AppImage       
ELFAI>�F@@��@@ @@@@@�@@@@���� ����b��b� `�`�b`�b�@@  P�tdjjBjB�...

So I guess the file was there in the container the whole time (why can't I browse docker containers in Dolphin?), and my adding anything to Manjaro's /opt directories didn't make any difference like you were saying. The problem is Ubuntu seems to be unable to executing AppImages, which is why I suspect that the container is lacking libraries and other system files that a full-fledged desktop ISO would have (I mean, it doesn't even have less)...

[neurodiverseEsoteric]

Just tried a different random appimage, and the same thing happened:

arbitrator@7291cf71b560:/$ cd ~
arbitrator@7291cf71b560:~$ ls
arbitrator@7291cf71b560:~$ wget https://dl1.pling.com/api/files/download/j/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MTUzNzk4NDQwNiwidSI6bnVsbCwibHQiOiJkb3dubG9hZCIsInMiOiJlNTIzMjZjM2QzYjQzYzU1ODU3M2E1NDZkMjQzMWMyMzllMzI4NzdkZjQzZDAzZTliMGQyYjE2NzkxYzgwZGE5ZDAwZDMzN2E1MDhkNGMwNjVkM2U2NDBmNDY2ZWYzYjcyNGZlZjY3NWU1MDA4MGZmMmFiMTNkZmNiYjg4ZmRiOCIsInQiOjE2NDgyNDMwMjIsInN0ZnAiOm51bGwsInN0aXAiOm51bGx9.AacDEJpZ_o9UzryCrmBpDSr_4QGjk0lKFCIRK6VZ-To/dust3d_unstable-x86_64.AppImage 
--2022-03-25 20:19:40--  https://dl1.pling.com/api/files/download/j/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MTUzNzk4NDQwNiwidSI6bnVsbCwibHQiOiJkb3dubG9hZCIsInMiOiJlNTIzMjZjM2QzYjQzYzU1ODU3M2E1NDZkMjQzMWMyMzllMzI4NzdkZjQzZDAzZTliMGQyYjE2NzkxYzgwZGE5ZDAwZDMzN2E1MDhkNGMwNjVkM2U2NDBmNDY2ZWYzYjcyNGZlZjY3NWU1MDA4MGZmMmFiMTNkZmNiYjg4ZmRiOCIsInQiOjE2NDgyNDMwMjIsInN0ZnAiOm51bGwsInN0aXAiOm51bGx9.AacDEJpZ_o9UzryCrmBpDSr_4QGjk0lKFCIRK6VZ-To/dust3d_unstable-x86_64.AppImage
Resolving dl1.pling.com (dl1.pling.com)... 46.101.144.174
Connecting to dl1.pling.com (dl1.pling.com)|46.101.144.174|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22271928 (21M) [application/octet-stream]
Saving to: 'dust3d_unstable-x86_64.AppImage'

dust3d_unstable-x86_64.AppImage        100%[===========================================================================>]  21.24M  5.44MB/s    in 4.2s    

2022-03-25 20:19:50 (5.04 MB/s) - 'dust3d_unstable-x86_64.AppImage' saved [22271928/22271928]

arbitrator@7291cf71b560:~$ chmod +x dust3d_unstable-x86_64.AppImage
arbitrator@7291cf71b560:~$ ./dust3d_unstable-x86_64.AppImage
bash: ./dust3d_unstable-x86_64.AppImage: No such file or directory

The fact that the container has no internet connection while I'm using a VPN also reinforces my feeling that the Ubuntu OS in the container is too minimal an installation...

[namaenonaimumei]

The problem is Ubuntu seems to be unable to executing AppImages, which is why I suspect that the container is lacking libraries and other system files that a full-fledged desktop ISO would have (I mean, it doesn't even have less)...

AppImages - as opposed to flatpaks or snaps - don't require any additional dependencies or setup to run them. Distributed .AppImage is effectively a self contained package embedded into ELF file, so it's just an executable - any Linux based distribution should be able to at least execute it.

It not having basic gnu utils like less is expected, as all additionally installed dependencies can be seen in first lines of Dockerfile and since when creating this image I had to create dependencies tree for it, I can tell it's not kind of error you would get from simply missing a library - this seems more like it fails way before loading dependencies, maybe even on filesystem level (unlikely, but would point to docker itself being misconfigured somehow or missing some vital dependency for your system). So from what I can tell, either file inside container is corrupted (unlikely, can check with md5 like below), architecture of .AppImage binary is different than what docker setup (not sure how that would happen) or it's actually some very low level dependency missing (which I wouldn't really go with since I tested container before with VM running basic image of arch+docker install as well).

Either way for attempt of troubleshoting all these, can you send uname -a output of both host (locally in terminal) and from inside container (same way you did previously with docker run --privileged -ti --user 1000 --entrypoint=bash criptext_f_02), other than that, inside container output of these

file /bin/cat
file /opt/criptext/Criptext.AppImage
md5sum /lib64/ld-linux-x86-64.so.2
md5sum /opt/criptext/Criptext.AppImage
ls -al /opt/criptext/

Also manjaro ships with ext4 by default, but in case you use btrfs is optional package btrfs-progs installed.

The fact that the container has no internet connection while I'm using a VPN also reinforces my feeling that the Ubuntu OS in the container is too minimal an installation...

docker-compose.yml includes setting to forward your hosts whole network configuration (network_mode: host), so VPN should not lock container out of network (at least on my side openvpn/tor connections work just fine) - possibly whatever IP/DNS your VPN used was blacklisted/misconfigured for connecting to ubuntu package repositories (if you meant issues building from previous reply).

is there a way to use a more fleshed out version like ubuntu KDE or something?

Since you meant base docker image, there are - but - it also has to be based on version release distribution that provides such images (so not ones considered rolling) and if distribution uses different package manager than apt (say fedora dnf), it would require you to rewrite all calls to apt inside Dockerfile to corresponding counterpart packages - that being said, with Ubuntu images you can install any package available from ubuntu (debian) repository from Dockerfile (each change to that file requires container rebuild, if it fails it requires clean --no-cache rebuild). To add, ubuntu is considered more of on a heavy-side image for docker already. So in short, don't bother looking around for other bases to use for this case - maybe you could test around with different image versions (currently used being ubuntu:20.04), but I don't know what would that change and may cause more issues than fix your current problems.

[neurodiverseEsoteric]

My Manjaro is normal (ext4), but everyone in both the Arch and Majaro forums are constantly saying "Manjaro is not Arch," and I've been trying to suppress the fear that the differences might actually having something to do with this issue, but I don't know if I could have kept going without mentioning it for much longer...

Anyway here is my output:

docker run --privileged -ti --user 1000 --entrypoint=bash criptext_f_02
arbitrator@e09afdd024da:/$ file /bin/cat
/bin/cat: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b357ed53c8c9cb1a312f83b28982304effae0135, for GNU/Linux 3.2.0, stripped
arbitrator@e09afdd024da:/$ file /opt/criptext/Criptext.AppImage
/opt/criptext/Criptext.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped
arbitrator@e09afdd024da:/$ md5sum /lib64/ld-linux-x86-64.so.2
77f0d391dd875daf0825fb69f1034d89  /lib64/ld-linux-x86-64.so.2
arbitrator@e09afdd024da:/$ md5sum /opt/criptext/Criptext.AppImage
ebea8a4ef2fcf8ddb3d6db70d8370fdc  /opt/criptext/Criptext.AppImage
arbitrator@e09afdd024da:/$ ls -al /opt/criptext/
total 116544
drwxr-xr-x 1 root root      4096 Mar 25 00:41 .
drwxr-xr-x 1 root root      4096 Mar 25 00:41 ..
-r-xr-xr-x 1 root root 119323289 Oct 30  2020 Criptext.AppImage
-r-xr-xr-x 1 root root       635 Mar 23 00:16 ep

The permissions on ep and Criptext.AppImage might be because I tried added a+rx to them as user=root after I got the "no such fire" error... The VPN issue was also post-docker-creation. I meant I had no internet connection at all (couldn't wget anything)

[namaenonaimumei]

everyone in both the Arch and Majaro forums are constantly saying "Manjaro is not Arch," and I've been trying to suppress the fear that the differences might actually having something to do with this issue, but I don't know if I could have kept going without mentioning it for much longer...

It's the same analogy as Ubuntu not being Debian - while there are various customization steps preadded for user friendliness to those compared to their base (like slight kernel patches, using dedicated servers to provide packages and so on), it still uses (for most) packages same as arch repository, builds directly ones from AUR, main parts of system remain unchanged as well. To add on top of that that, docker is a virtualization software, which aims to make running software host agnostic - at least the software part of it. In other words don't worry about these kind of differences too much - it won't matter in most cases - what will matter more are in this case your configuration files and some maybe some packages (software) clashes (like whatever causes your VPN connection issues inside docker).

To rest you assured though, I tested with a separate clean VM using Manjaro KDE Plasma Minimal and there were no issues. Just in case here are the steps to replicate my attempt (you can confirm whether you didn't do anything out of order, but there isn't much to setup as you can see).

# After running Manjaro installer with all defaults
sudo pacman -Syu docker docker-compose
systemctl enable docker.service
systemctl start docker.service
sudo usermod -a -G docker $USER
sudo reboot # to apply group permissions
# This is just deploying criptext-container_fix02.tar.gz version onto vm
mkdir ~/deploy-criptext
cd ~/deploy-criptext
wget 127.0.0.1:8080/shared/manjaro-docker/criptext-container_fix02.tar.gz
tar xf criptext-container_fix02.tar.gz --one-top-level
cd criptext-container_fix02
mkdir -p ~/.config/Criptext # This is just here in case ~/.config/Criptext doesn't exist (like in case of new machine) so docker doesn't create one as root
# ends here
./criptext-container # builds with no issues and launches criptext welcome window as expected

---

The permissions on ep and Criptext.AppImage might be because I tried added a+rx to them as user=root after I got the "no such fire" error...

That's actually correct permissions set in Dockerfile (since555/r-x^3 assures that no file will be modified without first changing its permission).

---

Getting back to your issues, entire output on your side seems as expected (same sums, no architecture inconsistencies). You didn't post output of uname -a (both host and container), but that was mostly to confirm whether your host is something else then x86_64, which I think you would mention at this point.

For now, since I can't replicate that No such file or directory message, I can only assume it's something really basic on docker side failing or some package incompatibility causes that (which is both very unlikely and pretty hard for me to diagnose) and can only advice to remove docker entirely (with clearing all configs and whatsoever remains) and reinstall, which may not even help, but is worth a try anyway. If you don't want to do that, you may backtrack a little and try some of things I mentioned above. In case of reinstalling docker you can try something like below (note I didn't really ever need to reset docker to default state, so this may still miss some docker config files)

docker rm -f $(docker ps -a -q)
docker system prune --volumes -a -f
sudo pacman -Rsn docker docker-compose
rm -rf ~/.docker/
sudo rm -rf /etc/docker/
# should probably reboot
sudo pacman -S docker docker-compose
sudo systemctl enable docker.service
sudo systemctl start docker.service
sudo usermod -a -G docker $USER
# reboot to apply usermod changes

[neurodiverseEsoteric]

If it's a botched docker setup it'll take a while for me to feel up to fixing it. However I do have a laptop I recently replaced the HDD and therefore have a fresh, clean Manjaro running on it, so maybe I'll try these steps there first...

[neurodiverseEsoteric]

Whelp I had to reboot anyway because I discovered via genymotion/virtualbox that I didn't have virtualization enabled in the BIOS (which gave it a weird acronym so it would be easy for me to miss). So re-installing docker and adding my ${USER} to the group didn't change anything, so I followed the absolute purge you suggested with

docker rm -f $(docker ps -a -q)
docker system prune --volumes -a -f
sudo pacman -Rsn docker docker-compose
rm -rf ~/.docker/
sudo rm -rf /etc/docker/
# should probably reboot
sudo pacman -S docker docker-compose
sudo systemctl enable docker.service
sudo systemctl start docker.service
sudo usermod -a -G docker $USER
# reboot to apply usermod changes

I didn't have a ~/.docker folder, but the ArchWiki mentions removing /var/docker which I found applied to Manjaro as well. When I got to the pacman steps I noticed something: Packages (5) bridge-utils-1.7.1-1 containerd-1.6.1-1 runc-1.1.0-1 docker-1:20.10.12-1 docker-compose-2.3.3-1 There was this package containerd which didn't come into focus until now. I tend to assume names like that with a added "d" at the end have something to do with "systemd," and then I wondered if containerd was also a service that needed to be enabled and running for docker to work. So on that hunch I went and did this:

sudo systemctl enable containerd
Created symlink /etc/systemd/system/multi-user.target.wants/containerd.service → /usr/lib/systemd/system/containerd.service.
sudo systemctl start containerd

Now I need to reboot again since I made the group change. Hopefully this gets criptext-container fully working. Otherwise, I might just add the working version of libgtk-3 in the pamac-installed criptext directory since that works for the extracted AppImage when I tested it....

[neurodiverseEsoteric]

Even after all that...

./criptext_container
Sending build context to Docker daemon  1.231kB
Step 1/17 : FROM ubuntu:20.04
 ---> ff0fea8310f3
Step 2/17 : RUN apt-get update
 ---> Using cache
 ---> 6d45fefcb71d
Step 3/17 : RUN apt-get install -y fonts-noto locales
 ---> Using cache
 ---> f1194a3ca110
Step 4/17 : RUN apt-get install -y libx11-xcb-dev dbus-x11 xauth
 ---> Using cache
 ---> f297256572c3
Step 5/17 : RUN apt-get install -y libnss3 libsecret-1-0 gnome-keyring
 ---> Using cache
 ---> a98119f92552
Step 6/17 : RUN apt-get install -y libasound2
 ---> Using cache
 ---> ae780593dc90
Step 7/17 : RUN apt-get install -y wget
 ---> Using cache
 ---> 9bb5281dd000
Step 8/17 : RUN locale-gen --no-purge ${LANG}
 ---> Using cache
 ---> 65af7a4c9aa7
Step 9/17 : COPY docker_ep.sh /opt/criptext/ep
 ---> Using cache
 ---> 88cfb4535e92
Step 10/17 : RUN chmod 555 /opt/criptext/ep
 ---> Using cache
 ---> 29f02514719d
Step 11/17 : RUN wget https://cdn.criptext.com/Criptext-Email-Desktop/linux/Criptext-latest.AppImage -O /opt/criptext/Criptext.AppImage
 ---> Using cache
 ---> e394cdd99d0c
Step 12/17 : RUN chmod 555 /opt/criptext/Criptext.AppImage
 ---> Using cache
 ---> 2dfc0664e503
Step 13/17 : RUN groupadd -g 1000 arbitrator
 ---> Using cache
 ---> c540bf1d7b06
Step 14/17 : RUN useradd -d /home/arbitrator -s /bin/bash -m arbitrator -u 1000 -g 1000
 ---> Using cache
 ---> 4a0a54cd3eca
Step 15/17 : USER arbitrator
 ---> Using cache
 ---> 3a24988705f3
Step 16/17 : ENV HOME /home/arbitrator
 ---> Using cache
 ---> 3292c8e0ad15
Step 17/17 : ENTRYPOINT ["/opt/criptext/ep"]
 ---> Using cache
 ---> a97e41411bb1
Successfully built a97e41411bb1
Successfully tagged criptext_f_02:latest
non-network local connections being added to access control list
[+] Running 1/0
 ⠿ Container criptext-react-fix_02  Created                                                                                                           0.0s
Attaching to criptext-react-fix_02
criptext-react-fix_02  | /opt/criptext/ep: line 17: /opt/criptext/Criptext.AppImage: No such file or directory
criptext-react-fix_02 exited with code 127
non-network local connections being removed from access control list

[namaenonaimumei]

There was this package containerd which didn't come into focus until now. I tend to assume names like that with a added "d" at the end have something to do with "systemd," and then I wondered if containerd was also a service that needed to be enabled and running for docker to work.

That service doesn't need to be enabled (also d in these cases usually stands for daemon, e.g. systemd=system daemon).

---

I didn't have virtualization enabled in the BIOS

I am pretty sure Docker requires virtualization enabled to run, so not really sure how it worked until now without it (unless you had to enable some additional virtualization features, since depending on your system configuration looks different)

---

Otherwise, I might just add the working version of libgtk-3 in the pamac-installed criptext directory since that works for the extracted AppImage when I tested it....

This may work temporary, but it may break again on some different libraries next - in that case your best bet would be to get all dependencies version frozen - you can get around to that by using Arch archive for getting specific package versions and adding LD_LIBRARY_PATH=/path/to/dir/with/old/libraries/.so before running extracted version of Criptext-latest.AppImage directly. You may take Dockerfile from any criptext-container as reference (granted these are debian package names) for what additional packages are required to run and if you can read shell scripts this may work as reference for how whole thing would look like in more automatized manner (this is what I use for apps like waifu2x-caffe, since that app is pretty inconsistent to maintain builds for, on rolling distributions).

Granted, if possible it's safer to run apps like that at least partially separated from main system, which docker solution does (since otherwise you are effectively running outdated version of libraries directly on your system, when starting the program, which may have some vulnerabilities/exploits found already - not saying you have to worry about that, just a notice if you care about such things).

---

As for main issue I don't have any other idea at the moment as for what could be causing this other than this being typically an error, when trying to run binaries with mismatched architecture, but as it's a pretty generic message it may be something entirely different in which case it's probably specific to your machine - if you try on your separate notebook (remember to create ~/.config/Criptext on your new system if it's not there before running container, since docker will create missing directories as root) and issue remains I'm going to look into it again.

[neurodiverseEsoteric]

I followed all of the steps, ~/.config/Criptext included, on the notebook. Same issue :( ...Would using firejail to run criptext mitigate the library vulnerabilities?

[namaenonaimumei]

If you get it working inside firejail - then yes.

As for notebook, if it's really still the same file error - since I take you just installed fresh system on it - can you send me link to manjaro iso version you used, if it's any different than what I tested with (KDE minimal). I'll check again just in case some package provided in version you used could be causing that.

[neurodiverseEsoteric]

firejail criptext runs fine aside from a random and ignorable error regarding chroot. But when I tried the firejail-profile-builder for criptext, the resulting profile didn't crash but it didn't do anything else either. No indication of it it failed, crashed, or was hung up, etc. I don't know what needs to be permitted to run or what feature should be disabled, either...Hopefully the default profile is secure enough for an already end-to-end encrypted service. As for Manjaro, I used the plain ol' regular normal download, not the minimal/LTS one(s), though I do have all the supported kernels from 5.10.something to 5.15.something installed as well.