TerraMaster Forum

Hello,

I’m using a TerraMaster NAS with TOS 5.1 and have encountered an issue with encrypted shared folders.

When I create an encrypted shared folder using a password that contains the $ symbol (e.g., Test$1234), the folder is created successfully. However, when I try to decrypt or unlock it later using the same password, the system fails to recognize it and displays an error that the decryption key is incorrect.

To troubleshoot, I tried the following:

Created a test encrypted shared folder without the $ symbol in the password — and it worked as expected.

Created another test folder with the $ symbol — again, it fails to decrypt.

I also tried saving the encryption key to a file during folder creation, and later importing that key file when trying to decrypt — but even that doesn't work if the password contains the $ symbol.

It seems the system mishandles passwords with special characters, especially $. This makes it impossible to access encrypted data if such a symbol is included in the password.

How can I recover access to my encrypted shared folder with a $ in the password?
Is this a known issue in TOS 5.1, and is there any workaround or fix?

Thank you for your assistance!

LosGuns wrote: ↑17 Apr 2025, 18:02

Hello, we need to conduct verification before giving you a definite reply. Thank you for your feedback. Currently, we haven't encountered this issue ourselves, but we don't deny that it may indeed exist.

Update:
After further testing, I discovered that the issue happens only when the encryption key contains a double dollar sign ($$).

For example, I tried using the password TEST12$$. The folder was created and encrypted successfully, but afterward it cannot be decrypted — neither by entering the password manually nor by using the saved encryption key file.

However, if I use TEST12$ (with just one dollar sign), everything works fine — encryption and decryption both succeed.

It seems the issue is specifically triggered by the presence of two dollar signs in a row.
Please clarify:

Is this a known issue or bug?

Does the system interpret $$ in a special way internally (e.g. shell escaping)?

Is there a correct way to escape or use such characters in encryption keys?

I've recorded a video demonstrating the issue:
https://youtu.be/J25BZWgbK9U ← (replace this with your actual video link)

TMnick wrote: ↑17 Apr 2025, 22:21

LosGuns wrote: ↑17 Apr 2025, 18:02

Hello, we need to conduct verification before giving you a definite reply. Thank you for your feedback. Currently, we haven't encountered this issue ourselves, but we don't deny that it may indeed exist.

It seems that the issue may be caused by the system interpreting $$ as a special shell sequence (e.g. $$ in many systems returns the current process ID).
If the encryption key is passed through a shell or scripting layer without proper escaping, TEST12$$ might be transformed into TEST12<somePID>, which would explain why decryption fails afterward.