2

I have two QNAPs that I can connect using SSH:

  • TS-412
  • TS-851

On the TS-851, right after login, if I type "é" on my keyboard, it shows "é" on the screen. On the other side, the TS-412, doesn't print the character on the screen. So, I can't access anything containing any accented characters (still through SSH).

I searched and all I find was about an SMB issue, but that's not my case. Shared folders appear correctly. Listing the folders via SSH shows up all accented characters. But, typing, and pasting one doesn't get to the box. Even auto-completion of paths strips the accented characters.

The locale is the same on both. Everything seems the same, but clearly, something is not.

I know QNAP has there own Linux flavor and I already asked in their forums, but in case of someone here would know. Because, I think this issue seems more like a generic Linux issue (not saying it is all over, but it is not specific to QNAPs).

That's really annoying!

Edit #1 - Answering questions

Execution of locale on my PC:

LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

Execution of locale on the TS-412:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Execution of locale on the TS-851:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Output for echo $TERM $SHELL the same on all machines:

xterm-256color /bin/bash

Output for uname -a on my computer, TS-412, TS-851 (in order):

Linux COMPUTER_NAME 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Linux QNAP_TS_412_NAME 3.4.6 #1 Thu Nov 24 07:58:16 CST 2022 armv5tel unknown


Linux QNAP_TS_851_NAME 5.10.60-qnap #1 SMP Thu Jan 12 01:41:46 CST 2023 x86_64 GNU/Linux

All the devices are up to date to their latest version, but TS-412 and TS-851 aren't the same version, because the TS-421 is too old to be updated to version 5.

TS-412 version: 4.3.3.2211

TS-851 version: 5.0.1.2277

Edit #2 - Patch

I can circumvent the issue writing a script doing what I want to execute containing accented chars and then run it. It works, but... not practical.

Edit #3 - New tests

locale -a

It gives the same results on both QNAPs:

C
en_US.utf8
POSIX

cat test

Typing cat <Enter> <é>, the character appears. <CTRL+D>, the character appears again. <CTRL-D>, cat exited.

vi test

When I launch vi I can type é and it appears.

The last two tests tell me that there is something in the shell input line that blocks some characters.

Master DJon
  • 191

1 Answers1

5

I found a solution with the help of @KamilMaciorowski

Modifying /etc/inputrc to include set convert-meta off did it.

Due to QNAPs special OS, this modification did not survive reboot, but following https://wiki.qnap.com/wiki/Running_Your_Own_Application_at_Startup and making the script to modify the file accordingly, it works!

There is an issue though, but small enough to live with it for now:

Type é, I have to backspace twice to erase the character. So:

[user@QNAP_NAME ~]$ echo "ABé"
ABé
[user@QNAP_NAME ~]$ echo "AB" ==> DID one backspace
AB�
[user@QNAP_NAME ~]$ echo "A" ==> No "é"
A
[user@QNAP_NAME ~]$ echo "A" ==> Typed "A", "B", "é", two backspaces
AB

So, what we see is no more reflecting the real string, but hey, do not erase and it will ok!

If someone finds/knows why, I'll modify my answer.

Master DJon
  • 191