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.