Docker installation missing offline support

[MrPointer]

Describe the bug
It seems that the docker images of the beta version (latest and previous) don't quite support offline mode as the standard installation does. The heart of the problem lies at the sideloading feature, which is key to supporting a fully offline solution.

The sideloading wiki-page only specifies instructions for standard installations, but it's inferrable that a similar process holds for docker installations, using paths relative to the image.
So I went on to try it by binding volumes between a local data/sideload directory, containing the required locale files, and /wiki/data/sideload, which I assume is the required path in the image.
However, the container constantly gets stuck in a "boot-loop" with the following error message:

EACCESS: permission denied, mkdir '/wiki/data/uploads'

I've attempted several other approaches, all without success:

• Validating user & group modifiers on the mounted local volumes have permissions to the docker group
• Changing ownership on mounted local volumes to a user with id 1000 (similar to image's inner-user node), which is part of the docker group
• Mounting files explicitly instead of the whole directory
• Creating all folders that already exist under image's /wiki/data folder locally, then mounting the entire data directory or just the data/sideload directory

At last, I tried to mount the files explicitly to the /wiki/ directory, then attach to the container's terminal (using docker exec -it wiki bash), create the data/sideload directory and manually copy the files there.
While it didn't crash with the error previously mentioned, the logs showed that the server has successfully read the locales yet it didn't display it in the browser - All names were field names taken (probably) from code, which seems to be another issue.

Host Info:

• OS: Docker on top of Ubuntu 16.04
• Wiki.js version: 2.0.0-beta.303
• Database engine: MySQL 8.0

Additional context
It's also worth mentioning that I did set the offline option in the configuration file to true.

[MrPointer]

Update: Today I learned about docker's volume-binding ro options (which stands for read-only), so I wondered what effect it would have on our scenario.
It turns out that if I read-only mount the /wiki/data path, it no longer complains about permissions, it does read the locales correctly, but when I try to create a new page, it fails on saving, since it can't write to the data directory at all (it is read-only now, is it?)
So just another insight for you to have...

[defteame]

@MrPointer I managed to get rid of "EACCESS: permission denied" error when mounting sideload folder by forcing root user within wiki container ("user: root" option in docker-compose file or --user=root for docker run). To get rid of placeholder text and errors, you have to reapply site locale in locale settings

[MrPointer]

@defteame It's good to read that you've managed to overcome this issue, yet I keep asking myself - Isn't it not-recommended to run the container as root? especially in prod environments.
I understand that it seems now as the only working solution, but if it requires root access... IDK 😐

[NGPixel]

@MrPointer The user inside the container runs as root. You're not giving root access for the whole system. These are 2 different things.

[MrPointer]

@NGPixel Agreed. However, doesn't it mean the image should run as root by default? I don't believe the user that runs the container should specify this, I think it should be "abstracted" away.

Edit: After doing some additional reading I've come across this blog post which clearly states why it's not such a good idea to run containers as root after all, somewhat aligned with my previous comment.
In our scenario, the approach recommended by the blog post is indeed taken as the image explicitly runs as a non-root user by default, however - It seems to come at the expense of volume bindings, and I'm not at all sure it's even up to you...
I honestly don't know why that happens, especially since my host UID and container-UID are the same.

[Aetherus]

My installation (on Docker Swarm) does not recognize the locale files at all. I've downloaded the locale files from https://github.com/Requarks/wiki-localization and put them in the locales folder. Here's part of my docker-compose.yml:

version: '3.7'

services:
  wiki:
    image: requarks/wiki:2
    user: root
    volumes:
      - ./config.yml:/wiki/config.yml:ro
      - ./locales:/wiki/data/sideload
    ...

And here is the content of config.yml (docker cp'ed from the container and added only the offline: true):

port: 3000
bindIP: 0.0.0.0
db:
  type: $(DB_TYPE)
  host: $(DB_HOST)
  port: $(DB_PORT)
  user: $(DB_USER)
  pass: $(DB_PASS)
  db: $(DB_NAME)
  storage: $(DB_FILEPATH)
  ssl: $(DB_SSL)
ssl:
  enabled: $(SSL_ACTIVE)
  port: 3443
  provider: letsencrypt
  domain: $(LETSENCRYPT_DOMAIN)
  subscriberEmail: $(LETSENCRYPT_EMAIL)
logLevel: info
ha: $(HA_ACTIVE)

# The only line I added
offline: true

The locale configuration seems to have been loaded because I saw Imported 43 locale packages: [ COMPLETED ] in the log, but the UI still shows things like welcome.title and fields.emailUser nonetheless.

When I visit /a/locale, I can see all the locales are there, but the availabilities are all 0%.

[SayidHosseini]

@MrPointer, @NGPixel, @defteame and @Aetherus, I think that this problem is resolved right now (using version 2.5.170).

Here is the docker-compose.yml file that I'm using:

version: "3"
services:

  db:
    image: postgres:11-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    logging:
      driver: "none"
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data

  wiki:
    image: requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
      OFFLINE_ACTIVE: 1
    restart: unless-stopped
    ports:
      - "80:3000"
    volumes:
      - ./sideload:/wiki/data/sideload
      - ./config.yml:/wiki/config.yml

volumes:
  db-data:

And here is the config.json file:

port: 3000
bindIP: 0.0.0.0
db:
  type: $(DB_TYPE)
  host: '$(DB_HOST)'
  port: $(DB_PORT)
  user: '$(DB_USER)'
  pass: '$(DB_PASS)'
  db: $(DB_NAME)
  storage: $(DB_FILEPATH)
  ssl: $(DB_SSL)
ssl:
  enabled: $(SSL_ACTIVE)
  port: 3443
  provider: letsencrypt
  domain: $(LETSENCRYPT_DOMAIN)
  subscriberEmail: $(LETSENCRYPT_EMAIL)
logLevel: info
ha: $(HA_ACTIVE)
offline: $(OFFLINE_ACTIVE)

I think the offline mode support can be built more into the container.
For starters, the OFFLINE_ACTIVE environment variable can be added to the repository's config.json file.
Moreover, for people installing the wiki.js behind a proxy, it would be a good idea to check if the offline mode has been set; and if set, it then would clone the latest locales from the Git repository using the given proxy to the container. It also can be updated each time the container gets started or restarted. This could be either a separate environment variable or a loose check; to support people installing with no internet connectivity.

However these ideas can be issued separately and I think this issue can be closed.

[ebousse]

I agree that it would be great to have an automatic "fallback mode" that would work when offline is enabled.