Process exited with code 14

[Tivin-i]

⚠️ Please verify that this bug has NOT been reported before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

Error appears in the logs as shown below.
Dockge is working as expected, all stacks are up and operational, I checked everything one by one.

👟 Reproduction steps

Was creating stacks as usual, all stacks that should be up are up.

👀 Expected behavior

descriptive error on where configuration might be missing.

😓 Actual Behavior

Error showing in logs.

Dockge Version

1.4.2

💻 Operating System and Arch

Ubuntu 22.04

🌐 Browser

CLI

🐋 Docker Version

Docker version 25.0.4, build 1a576c5

🟩 NodeJS Version

No response

📝 Relevant log output

2024-03-18T11:28:28Z [GETSERVICESTATUSLIST] ERROR: Error: Process exited with code 14
    at ChildProcess.done (/app/node_modules/.pnpm/[email protected]/node_modules/promisify-child-process/index.cjs:70:19)
    at ChildProcess.emit (node:events:514:28)
    at ChildProcess.emit (node:domain:489:12)
    at maybeClose (node:internal/child_process:1091:16)
    at ChildProcess._handle.onexit (node:internal/child_process:302:5) {
  code: 14,
  signal: null,
  stdout: '',
  stderr: 'no configuration file provided: not found\n'
}

[explorer369]

I also encountered this problem, but I don't know how to solve it myself。

dockge_1 | 2024-04-12T02:56:20Z [GETSERVICESTATUSLIST] ERROR: Error: Process exited with code 14
dockge_1 | at ChildProcess.done (/app/node_modules/.pnpm/[email protected]/node_modules/promisify-child-process/index.cjs:70:19)
dockge_1 | at ChildProcess.emit (node:events:514:28)
dockge_1 | at ChildProcess.emit (node:domain:489:12)
dockge_1 | at maybeClose (node:internal/child_process:1091:16)
dockge_1 | at ChildProcess._handle.onexit (node:internal/child_process:302:5) {
dockge_1 | code: 14,
dockge_1 | signal: null,
dockge_1 | stdout: '',
dockge_1 | stderr: 'no configuration file provided: not found\n'
dockge_1 | }

[alejandroperezlopez]

Same here, everytime I visit the "compose" tab for creating a new stack.

[Dvalin21]

Same exact issue

[M1xel]

EDIT: I fixed the issue and it was indeed a permission error on my side.
I had forgot that I created a /etc/docker/daemon.json and put in

{
  "userns-remap": "userToRunDockerWith"
}

Which would mean that all services run with the user that is given in the configm which in return messed with the permission of dockge.

I experience the same exact Issue for me it started after a VM reboot.

I also get this error which indicated that the DB is readonly however the permissions didn't change.

2024-07-29T15:37:34Z [SERVER] INFO: Welcome to dockge!
2024-07-29T15:37:34Z [SERVER] INFO: NODE_ENV: production
2024-07-29T15:37:34Z [SERVER] INFO: Server Type: HTTP
2024-07-29T15:37:34Z [SERVER] INFO: Data Dir: ./data/
2024-07-29T15:37:34Z [DB] INFO: Database Type: sqlite
2024-07-29T15:37:34Z [SERVER] ERROR: Failed to prepare your database: PRAGMA journal_mode = WAL - SQLITE_READONLY: attempt to write a readonly database

in addition to the already provided exited with code 14

2024-07-29T15:36:27Z [GETSERVICESTATUSLIST] ERROR: Error: Process exited with code 14
at ChildProcess.done (/app/node_modules/.pnpm/[email protected]/node_modules/promisify-child-process/index.cjs:70:19)
at ChildProcess.emit (node:events:514:28)
at ChildProcess.emit (node:domain:489:12)
at maybeClose (node:internal/child_process:1091:16)
at ChildProcess._handle.onexit (node:internal/child_process:302:5) {
code: 14,
signal: null,
stdout: '',
stderr: 'no configuration file provided: not found\n'
}

[mr-gosh]

I encouter this behaviour on an unraid server with the deployment of the dockerge setup without changing anything - so its pretty basic.

[Akorian]

I use the userns-remap setting rather explicitly since I want a specific user to own the files in my volume mappings.
Is there a workaroud that allows me to keep using that setting or must I remove it?
@M1xel

[M1xel]

I use the userns-remap setting rather explicitly since I want a specific user to own the files in my volume mappings. Is there a workaroud that allows me to keep using that setting or must I remove it? @M1xel

Sadly I haven't tested it more and didn't try to find a fix just removed this setting and went on, I know this should be best practice because it minimizes permissions but I couldn't be bothered :')
I hope you find an adequate fix though!

[Akorian]

I would suppose since other containers work fine, that this is something that must be fixed by @louislam.
Appart form that I am trying to figure out a way around this but right know it seems dark ^^°