TOS 7.0.1169 (x86) Official Release Update

[AES]

TOS 7 Upgrade: Vaultwarden (Docker 1.37.2) fails to start on F8 SSD / UI Log pagination issue/b]

Hello,
I have recently updated my NAS to TOS 7.0.1169, and right after the update, my Vaultwarden container completely broke and refuses to start.
Device details:

* NAS Model: TerraMaster F8 SSD
* Current TOS Version: 7.0.1169
* App Version: Vaultwarden 1.37.2 (Docker / Container Manager)

The Issues:

1. Container crash loop: The container fails to launch and completely drops the web interface connection. It seems the network ports are also completely unreachable.
2. Terrible UI Log Pagination: I initially thought there were no logs because the TOS 7 Container Manager displays them in a highly counter-intuitive way. Instead of showing the newest entries first, it appends them to the very end. I had to manually click through to page 850+ just to find the actual current errors.

Here are the latest log lines from the very last page of the container log viewer:




Before the TOS 7 update, everything worked flawlessly with the exact same volumes and network configurations.
Could you please advise on how to fix this startup failure? Also, please pass feedback to the UI team to fix the log sorting in the Container Manager, as forcing users to scroll through hundreds of pages to see fresh logs is unacceptable.
Thank you.

[AES]

Caddy:


Terra Search (That was a very long time ago):


It is highly likely that the issue is related to the Caddy reverse proxy service, which I previously configured to handle the HTTPS connections and SSL certificates for Vaultwarden.

[AES]

TOS 7 Upgrade: Vaultwarden (Docker 1.37.2) fails to start on F8 SSD / UI Log pagination issue/b]

Hello,
I have recently updated my NAS to TOS 7.0.1169, and right after the update, my Vaultwarden container completely broke and refuses to start.
Device details:

* NAS Model: TerraMaster F8 SSD
* Current TOS Version: 7.0.1169
* App Version: Vaultwarden 1.37.2 (Docker / Container Manager)

The Issues:

1. Container crash loop: The container fails to launch and completely drops the web interface connection. It seems the network ports are also completely unreachable.
2. Terrible UI Log Pagination: I initially thought there were no logs because the TOS 7 Container Manager displays them in a highly counter-intuitive way. Instead of showing the newest entries first, it appends them to the very end. I had to manually click through to page 850+ just to find the actual current errors.

Here are the latest log lines from the very last page of the container log viewer:




Before the TOS 7 update, everything worked flawlessly with the exact same volumes and network configurations.
Could you please advise on how to fix this startup failure? Also, please pass feedback to the UI team to fix the log sorting in the Container Manager, as forcing users to scroll through hundreds of pages to see fresh logs is unacceptable.
Thank you.

I wanted to share my experience and the final solution for restoring a Vaultwarden (Docker) deployment after migrating to TOS 7 (7.0.1169) on a TerraMaster F8 SSD.
## Why it broke during the TOS 7 upgrade:

1. Port Collisions: The new TOS 7 system architecture highjacks previously popular custom container ports at the host network level (e.g., ports like 5443 or 6443 are now locked by internal system services via tcp6), forcing existing containers into an immediate Address already in use crash loop.
2. Strict TLS Engine Update: The updated container engine inside TOS 7 Container Manager no longer accepts an individual unified .pem file acting as both a certificate and a private key simultaneously via the ROCKET_TLS environment string. It silently drops connections with an ERR_INVALID_HTTP_RESPONSE error.
3. Case Sensitivity Shifts: The storage mount paths handler became completely unforgiving regarding Linux case sensitivity (e.g., passing /volume2/ instead of /Volume2/), resulting in Docker spinning up pristine empty directory nodes instead of reading the actual existing database.

------------------------------
## How we successfully fixed it:
If your Vaultwarden instance is stuck constantly restarting, use the TOS built-in Terminal app and execute the following sequential deployment patch:
Step 1: Extract separate certificate assets from the unified key
Navigate into your storage directory and split the certificate layer to satisfy the new engine constraints:

openssl req -new -x509 -key /Volume2/Docker/bitwarden/rsa_key.pem -out /Volume2/Docker/bitwarden/vault.crt -days 3650 -subj "/CN=f8-terramaster.local"

Step 2: Clear the broken container instance

docker rm -f vaultwarden-server

Step 3: Redeploy on a clean custom port with explicit Case-Sensitive volumes
Deploy using an unassigned host port (like 7443) and pass the newly separated TLS parameters to safely pull your existing database weights (e.g., db.sqlite3):

docker run -d --name vaultwarden-server \
-v /Volume2/Docker/bitwarden:/data \
-p 7443:443 \
-e ROCKET_PORT=443 \
-e ROCKET_TLS='{certs="/data/vault.crt",key="/data/rsa_key.pem"}' \
--restart unless-stopped \
vaultwarden/server:latest

Step 4: Update TOS Firewall Rules
Go to Control Panel -> Security -> Firewall, add a custom inbound rule allowing TCP port 7443, and apply changes.
After completing these steps, the Vaultwarden vault becomes fully operational via https://[NAS_IP]:7443 without any data loss. Hopefully, the dev team will fix the default port overlapping and counter-intuitive log pagination in upcoming updates.

[Metyrion]

Please fix the german translation in Virtual Machine Manager. When uploading an image the german word for image is still image not Bild, because Bild is picture and not a iso image. Please fix, thank you

[EriChan]

Thank you very much for sharing your update and solution with the community! We truly appreciate your feedback and support for TOS 7.

[EriChan]

Thank you for pointing this out and helping us improve our localization!

We have recorded this translation issue in VMs and forwarded it to our team to correct in an upcoming update.

Thank you again for your valuable feedback!

[mmick]

ATM with the 7.0.1169 I have the same issue as always (F4-423, 8 GB of RAM): despite the FIle Manager being improved it still has some (basic!) issues copying files.

Example occuring right now, at this moment:
- I have a USB HDD (it can be a SSD, pen drive, etc) and I want to copy around 15.000 files and 1 TB of data, to the NAS
- I plug in the device directly or with a high end USB 3.x cable and I go the TNAS File Manager, I select the folders, copy, paste
- Lets say that I have to stop copying for any reason (use the USB HDD/SSD, put more data, etc)
- When I select all folders again (as I do not know what has been copied already), copy, paste > it asks in case of duplicates, what I want to do, and I select -for example- SKIP. It does NOT do ANYTHING. But if I manually select folders that are not on the TNAS already, it will copy them normally!

Conclusions I took from my Tests:
- the File Manager does NOT seem to compare folders and what files are already there as a normal Linux / Windows / MacOS and then just copy what is not there or is different
- the File Manager should get TICK BOXES (extra or give the option to toggle on those Tick Boxes) > if I am on my phone / tablet, I cannot select several folders and copy those...
- I get the impression that the TNAS itself could use MUCH MORE free RAM to use a cache. It could analyse how much free RAM is left after all apps, VMs, etc are running and then adapt a reading / writing cache. I have 8 GB of RAM and 84% is not used on a normal day. But when I am copying a lot of files, perhaps you could test if a bigger RAM pool as cache would help...

Other than that, at the moment my only grip is with the FIle Manager.

[CursaYang]

If you can consistently reproduce the issue, please visit the link below to schedule a remote troubleshooting session with online support:
https://salesiq.zohopublic.com/signatur ... 97d0be8892