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

[merlin9876]

Well, everything seemed to go well with the TOS 7 update. Smooth process. I also applied this update (7.0.1169).

Unfortunately, whenever I boot the server up, after about 20 minutes, the server literally dissapears from my network, which it never did before. I can't find it on the network from my Windows 11 machine with the "arp -a" command, can't ping it, etc, etc. Even TNAS PC can't find it after that 20 minutes. I don't have any special firewalls, VPNs, etc. I don't have any special power configurations, no sleep for the hard disks, no nothing. It works perfectly and 20 minutes in, it dissappears. Not even my router sees it after 20 minutes in it's listed devices. I use a fixed IP address, as I always did.

Also tried specifying again the IP address in TNAS PC (in the 20 minutes I have) and it doesn't do anything, it doesn't prevent the vanishing. I'm on a F4-423 btw...

I can only get the server back by doing a hard reboot and then only have about 20 minutes. It's driving my crazy! Any help would be appreciated. Thanks you!

p.s.: the server is still running, just I can't see it on the network...

Oh my gosh! I'm not the only one with this problem. I just saw the post at viewtopic.php?t=10349&start=40 by plexjellyfin and we seem to have the exact same problem! I was in talks with a technician but the person is making me run various tests like memory or dockers but I can't see why these would matter. One day on TOS 6, no problem. Next day on TOS 7.0.1169 and this problem comes up. I am almost completely sure this has nothing to do with hardware troubles, the F4-423 was running absolutely fine the day before.

So, do you have any suggestions about this? Thank you! I'm anxiously waiting to get my server back soon. For now, it's like a brick...

[merlin9876]

Well, everything seemed to go well with the TOS 7 update. Smooth process. I also applied this update (7.0.1169).

Unfortunately, whenever I boot the server up, after about 20 minutes, the server literally dissapears from my network, which it never did before. I can't find it on the network from my Windows 11 machine with the "arp -a" command, can't ping it, etc, etc. Even TNAS PC can't find it after that 20 minutes. I don't have any special firewalls, VPNs, etc. I don't have any special power configurations, no sleep for the hard disks, no nothing. It works perfectly and 20 minutes in, it dissappears. Not even my router sees it after 20 minutes in it's listed devices. I use a fixed IP address, as I always did.

Also tried specifying again the IP address in TNAS PC (in the 20 minutes I have) and it doesn't do anything, it doesn't prevent the vanishing. I'm on a F4-423 btw...

I can only get the server back by doing a hard reboot and then only have about 20 minutes. It's driving my crazy! Any help would be appreciated. Thanks you!

p.s.: the server is still running, just I can't see it on the network...

Oh my gosh! I'm not the only one with this problem. I just saw the post at viewtopic.php?t=10349&start=40 by plexjellyfin and we seem to have the exact same problem! I was in talks with a technician but the person is making me run various tests like memory or dockers but I can't see why these would matter. One day on TOS 6, no problem. Next day on TOS 7.0.1169 and this problem comes up. I am almost completely sure this has nothing to do with hardware troubles, the F4-423 was running absolutely fine the day before.

So, do you have any suggestions about this? Thank you! I'm anxiously waiting to get my server back soon. For now, it's like a brick...

UPDATE : I've let the server run for several hours after not being able to connect to it. I was thinking maybe there were massive updates to conform to TOS 7 (file permissions and whatnot), so why not let it the OS try to sort it out and check progress on connection to the web interface about every 12 hours. Well... I'm so happy to say that I've managed to reconnect to the server tonight without rebooting! I hope it sticks and my server is back like before.
SUGGESTION : you should really put a notice for the TOS7 update to tell people it may take many hours to finalize the update correctly. I have several hundred thousands files and directories on my server. That may cause the bottleneck I've experienced... So, I guess I managed to solve my problem myself...