QuTS hero 6.0.0.3500: Existing encrypted shared folder password containing ":" no longer works after upgrade

English Storage
1

Hello,

I would like to report what appears to be a compatibility issue involving encrypted shared folders after upgrading to QuTS hero 6.0.0.3500.

Environment:

  • NAS: TS-673A

  • OS: QuTS hero h6.0.0.3500

  • Encrypted shared folder created on an older QTS/QuTS hero version

Important fact:

The encryption password contains a colon character (:).

This is not a newly created password. The same password had been working successfully for years before the upgrade. Therefore “:” characters were clearly accepted by the system at the time the encrypted shared folder was created.

Problem:

After upgrading to QuTS hero 6.0.0.3500, I can no longer unlock the encrypted shared folder or export the encryption key through Storage Manager.

The GUI immediately rejects the password with the following validation message:

“Password cannot contain " $ : = \ or spaces.”

Because the original encryption password contains a colon, the correct password can no longer be entered through the GUI.

Investigation:

I inspected the frontend code and found that the validation message is hardcoded in the Storage Manager frontend.

The encrypted dataset itself was not damaged.

Using SSH, I verified that:

  • The encrypted ZFS dataset still exists.

  • The dataset initially reported:

    • keystatus = unavail

  • After manually loading the key through SSH:

    • keystatus = avail

    • mounted = yes

After that:

  • SMB access works normally.

  • Windows Explorer access works normally.

  • macOS Finder access works normally.

  • All data is intact.

Backend API testing:

I also tested the key export API directly.

Request:

POST /api/storage/v1/volumes//encryption/key_file/download

The frontend sends the password through:

x-key:

I bypassed the frontend validation and submitted the original password directly to the API.

Result:

  • HTTP 200 OK

  • Content-Length: 0

  • Empty response body

Storage Manager generated the following system log entry and email notification:

[Storage Manager] Entered invalid encryption key.

This indicates that the issue is not limited to frontend validation. The backend also rejects the password even though it was previously valid and the encrypted dataset can still be unlocked manually through SSH.

Questions:

  1. Is this a known compatibility issue in QuTS hero 6.0.0.3500?

  2. Has the password validation logic for encrypted shared folders changed compared to older QTS/QuTS hero versions?

  3. Why is a password that previously worked for years now considered an invalid encryption key?

  4. Why does the key export API return HTTP 200 with an empty response instead of returning an error?

  5. Is there an official migration or recovery procedure for encrypted shared folders created with older password rules?

At the moment the data is safe because the dataset was manually unlocked through SSH, but the normal management path through Storage Manager is no longer functional.

Any feedback from QNAP staff or users who have experienced similar behavior would be appreciated.

2

Seems a serious problem. Did you you try filing a support ticket and what did they say?

3

Hi @elfshimomura ,

Thank you for sharing the detailed information and your investigation results.

To help us further verify this behavior, may we confirm which QTS/QuTS hero version the encrypted shared folder was originally created on, or which version you were using before upgrading to QuTS hero h6.0.0.3500?

Since this involves encrypted shared folder access and may require further review of your system environment, we recommend opening a support ticket via the QNAP Service Portal:

Our support team will assist with further investigation and handling in a timely manner.

Thank you again for reporting this case.

4

Hi Lucas,

Thank you for your reply.

I have already opened a support ticket with QNAP Japan Support via the QNAP Service Portal, and I have also provided the support log package through that ticket.

Regarding the previous version, I am still checking the logs, but I found the following in /etc/config/uLinux.conf:

[System]
Model = TS-X73A
Version = 5.2.8
Build Number = 20251225
Number = 3359
Build Date = 2025-12-25

So the system configuration currently shows 5.2.8 build 20251225 / number 3359.

This also seems consistent with the uptime before the upgrade. The NAS had been running for about 135 days before I upgraded to QuTS hero h6.0.0.3500, so it is likely that I was using QuTS hero 5.2.8 build 20251225 immediately before the upgrade.

I am not 100% sure which exact QTS/QuTS hero version was used when the encrypted shared folder was originally created. The NAS itself was purchased approximately 4 years ago, and I may have recreated the encrypted shared folder once after that, so I believe the encrypted shared folder was created approximately 3 to 4 years ago.

Until this upgrade, I had generally kept the NAS firmware up to date. I had rebooted the NAS many times after previous firmware updates, and each time I was able to unlock the same encrypted shared folder normally using the same password containing :. Therefore, the password containing : had been working normally not only when the folder was created, but also across multiple previous firmware updates and reboots.

The issue occurred only after upgrading to QuTS hero h6.0.0.3500.

I will continue checking the support log package to see if I can identify the exact version history.

5

Update:

QNAP Japan Support responded to my support ticket and escalated the case to their development team.

They provided guidance through the official support channel, and I was able to change the encrypted shared folder password to a new one that does not contain restricted characters.

After changing the password, I was able to export a valid encryption key file from Storage Manager. Previously, the exported file was 0 bytes, but it now exports correctly.

The data remains accessible.

I cannot share the detailed internal recovery procedure publicly, as it was provided through QNAP support, but I recommend opening a support ticket if anyone encounters a similar issue with an existing encrypted shared folder password containing special characters after upgrading to QuTS hero h6.0.0.3500.

I am still confirming the remaining status inconsistency, where the ZFS dataset is mounted and accessible, but some QNAP management tools still show the volume status differently.