TOS 7 Beta Is Available for Testing

[Lex]

did you solve the problem for immich ? i have the same issue

I copy folder with immich, remove original folder and copy back it.
In my case posgre can`t connect to database.

Code: Select all

immich_postgres          | initdb: error: could not access directory "/var/lib/postgresql/data": Permission denied
immich_postgres          | The files belonging to this database system will be owned by user "postgres".

Also it help for NextCloud.

did this solved the issue ?

Yes. Copy in mc.

Code: Select all

Using SSD storage

PostgreSQL Database directory appears to contain a database; Skipping initialization

2025-12-18 18:15:42.740 GMT [1] LOG:  skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf"
2025-12-18 18:15:42.741 GMT [1] LOG:  skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf"
2025-12-18 18:15:42.791 UTC [1] LOG:  starting PostgreSQL 14.19 (Debian 14.19-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2025-12-18 18:15:42.791 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2025-12-18 18:15:42.791 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2025-12-18 18:15:42.798 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
[2

[jdcesari]

I copy folder with immich, remove original folder and copy back it.
In my case posgre can`t connect to database.

Code: Select all

immich_postgres          | initdb: error: could not access directory "/var/lib/postgresql/data": Permission denied
immich_postgres          | The files belonging to this database system will be owned by user "postgres".

Also it help for NextCloud.

did this solved the issue ?

Yes. Copy in mc.

Code: Select all

Using SSD storage

PostgreSQL Database directory appears to contain a database; Skipping initialization

2025-12-18 18:15:42.740 GMT [1] LOG:  skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf"
2025-12-18 18:15:42.741 GMT [1] LOG:  skipping missing configuration file "/var/lib/postgresql/data/postgresql.override.conf"
2025-12-18 18:15:42.791 UTC [1] LOG:  starting PostgreSQL 14.19 (Debian 14.19-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2025-12-18 18:15:42.791 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2025-12-18 18:15:42.791 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2025-12-18 18:15:42.798 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
[2

i dont know whats is MC ?
i am really a newbie...

[Lex]

i dont know whats is MC ?
i am really a newbie...

Midnight Commander (or mc) is a visual, dual-pane file manager.

[jdcesari]

sorry i do not understand
anyway only with env and yml file ?

[abs1ck]

Hi everyone,

I’m having issues with Docker containers on my TerraMaster NAS running TOS 7.

Before the latest update, everything was working fine. After updating, my MariaDB container fails to start with the following error:

Code: Select all

[ERROR] Can't create/write to file './ddl_recovery.log' (Errcode: 13 "Permission denied")

I’ve tried the following:

Using chmod 777 on the database folder

Adding user: root in docker-compose

Setting ACLs with setfacl -PRdm u::rwx,g::rw,o::r /Volume1/...

Nothing works — the container still cannot write to the folder.

For reference, here is how the service is defined in my docker-compose.yml:

Code: Select all

db:
  image: 'jc21/mariadb-aria:latest'
  container_name: nginx_proxy_manager_mariadb
  networks:
    - network
  restart: always
  user: root
  environment:
    MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    MYSQL_DATABASE: ${MYSQL_DATABASE}
    MYSQL_USER: ${MYSQL_USER}
    MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    MARIADB_AUTO_UPGRADE: '1'
  volumes:
    - ./db:/var/lib/mysql
  env_file:
    - .env

It seems the update changed TOS 7’s sandbox or permissions handling for Docker, because previously everything worked correctly.

Has anyone encountered the same issue after the TOS 7 update? Is there a recommended way to make Docker containers write to folders on /Volume1/ again?

Thanks in advance for any advice!

[jpeckinp]

You can enable Debug Mode in the "Support & Help" section on the TOS desktop. This way, if another random shutdown occurs, the system will continuously generate debug logs up until the shutdown. Please download these logs and provide them to us so we can conduct an in-depth investigation.

Thanks, Enabled and we'll see what happens. No shutdowns since yesterday afternoon.

[ruzaj]

Cannot create a hyper cache after the update; the page becomes unresponsive.
Also, when willthe TOS7 Installation Package be available for fresh installation?

[TMnight]

At present, TOS7 only supports upgrading from existing versions and cannot be directly installed. Please follow the official website for updates on the installation package.
Can cache pages be used for creating operations?

[Lex]

Hi everyone,

I’m having issues with Docker containers on my TerraMaster NAS running TOS 7.

Before the latest update, everything was working fine. After updating, my MariaDB container fails to start with the following error:

Code: Select all

[ERROR] Can't create/write to file './ddl_recovery.log' (Errcode: 13 "Permission denied")

I’ve tried the following:

Using chmod 777 on the database folder

Adding user: root in docker-compose

Setting ACLs with setfacl -PRdm u::rwx,g::rw,o::r /Volume1/...

Nothing works — the container still cannot write to the folder.

For reference, here is how the service is defined in my docker-compose.yml:

Code: Select all

db:
  image: 'jc21/mariadb-aria:latest'
  container_name: nginx_proxy_manager_mariadb
  networks:
    - network
  restart: always
  user: root
  environment:
    MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    MYSQL_DATABASE: ${MYSQL_DATABASE}
    MYSQL_USER: ${MYSQL_USER}
    MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    MARIADB_AUTO_UPGRADE: '1'
  volumes:
    - ./db:/var/lib/mysql
  env_file:
    - .env

It seems the update changed TOS 7’s sandbox or permissions handling for Docker, because previously everything worked correctly.

Has anyone encountered the same issue after the TOS 7 update? Is there a recommended way to make Docker containers write to folders on /Volume1/ again?

Thanks in advance for any advice!

I have same problem for docker.
I just copy folder with DB (login by ssh), remove original folder and copy back DB. And docker run correctly.
It didn't work, and after a while it stopped working again

[abs1ck]

I have same problem for docker.
I just copy folder with DB (login by ssh), remove original folder and copy back DB. And docker run correctly.
It didn't work, and after a while it stopped working again

I tried this method, but it didn’t work — not even for a short time. The error didn’t go away