Persistence Failure on QNAP Docker Environment

[ivarmartin]

The problem

Host QNAP NAS (Model TVS h1288x QTS 5.2.6)

Docker Host: QNAP Container Station

Image: bbernhard/signal-cli-rest-api (Tested with :latest)

Deployment Method: Tested with both the QNAP Container Station GUI and command-line docker-compose.

Problem Description:

The container fails to persist its registration data at the internal path /home/.local/share/signal-cli under any circumstances. Data appears to be written only to the container's ephemeral storage layer, as it survives a docker restart but is lost upon container recreation (docker rm followed by docker run). This failure occurs with both bind mounts and Docker named volumes. A baseline test using a standard alpine image confirms that Docker named volumes are fundamentally functional on the host system, isolating the issue to this specific container's interaction with the QNAP Docker environment.

Steps to Reproduce:

Prepare a host directory on a QNAP share (e.g., /share/Public/docker/signal-data).

Set ownership of the directory via SSH to a known user (e.g., sudo chown -R 1000:100 /share/Public/docker/signal-data).

Deploy the container using the following docker-compose.yml:

YAML

services:
signal-api:
image: bbernhard/signal-cli-rest-api:latest
container_name: signal-api
restart: unless-stopped
volumes:
- /share/docker/signal-data:/home/.local/share/signal-cli
environment:
- SIGNAL_CLI_UID=1000
- SIGNAL_CLI_GID=100
- SIGNAL_CLI_CHOWN_ON_STARTUP=false
- MODE=json-rpc
Register a phone number successfully using docker exec ... register and verify.

Stop and remove the container stack using docker-compose down.

Recreate and start the container using docker-compose up -d.

Expected Result:
The container starts, reads its data from the persistent volume, and the registration is intact. A subsequent docker exec -it signal-api signal-cli -u receive command should function correctly.

Actual Result:
The container starts with a fresh state. A docker exec -it signal-api signal-cli -u receive command fails with the error "User is not registered." The data in the host directory is either never written or is empty.

Exhaustive Troubleshooting Steps Taken:

Confirmed that QNAP's "Advanced Folder Permissions" (ACLs) are disabled globally.

Attempted persistence using bind mounts to multiple host paths, including a subfolder, a new dedicated Shared Folder with guest RW permissions, a user's personal home directory, and the globally writable /public share. All attempts failed.

Attempted to fix permissions on the host directory using sudo chown with various users (including the container's internal UID 1000) and sudo chmod 777. These had no effect.

Attempted persistence using a Docker named volume. While this worked for a simple alpine container test, it failed for the signal-api container.

Tested multiple container MODEs (native, json-rpc).

Tested with SIGNAL_CLI_CHOWN_ON_STARTUP set to both true (default) and false. The failure persists in both cases.

Are you using the latest released version?

• Yes

Have you read the troubleshooting page?

• Yes

What type of installation are you running?

signal-cli-rest-api Docker Container

In which mode are you using the docker container?

Native Mode

What's the architecture of your host system?

x86-64

Additional information

No response

[bbernhard]

That's weird. Have you tried creating a dummy file inside the docker container with e.g touch test.txt to see if that file still exists after a docker container restart? Inside the docker container there is nothing special happening - it is simply using the standard file APIs for writing changes to the disk.