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
  • 151
  • 9
  • 1
    Please edit your question to include the output of the command `locale` for **(1)** Your PC, **(2)** TS-412 via SSH, and **(3)** TS-851 via SSH – Blind Spots Feb 19 '23 at 01:55
  • 1
    It might also be helpful to see the output of `echo $TERM $SHELL` and something like `uname -a` from each device. Also do you have up to date firmware/OS/software on both devices? Is the latest firmware/OS/software release for both devices the same version number, or different versions? – Spiff Feb 19 '23 at 02:31
  • @BlindSpots All the output is now in the question. – Master DJon Feb 19 '23 at 18:03
  • @Spiff Answers to your questions are now in the question. – Master DJon Feb 19 '23 at 18:03
  • (0) Do you `ssh` to the both systems in exactly the same way? How? // Inside the troublesome system: (1) Run sole `cat`. Type `é`. Does `é` appear? Press Ctrl+d. Does `é` appear? Press Ctrl+d, `cat` should exit. (2) What is the output of `locale -a`? (3) Run `LC_ALL=en_US.UTF-8 bash`. Can you type `é` now? (Exit the nested shell by invoking `exit`.) – Kamil Maciorowski Feb 20 '23 at 07:33
  • @KamilMaciorowski (0) I connect via SSH exactly the same on both systems. (1) Yes, `cat + + <é>`, it shows the character. First CTRL-D, another `é` appears, second, it exited `cat`. (2) See question Edit #3. (3) No in the nested shell, I still can't type `é`. – Master DJon Feb 20 '23 at 15:58
  • Thanks. Consider putting all this information into the question body. I'm afraid I cannot help you further. I have upvoted the question, this is the best I can do for now. – Kamil Maciorowski Feb 20 '23 at 16:01
  • @KamilMaciorowski Well, that's already, great. I already reduce a bit what's happening. – Master DJon Feb 20 '23 at 16:08
  • Oh, another idea. `é` is `303 251` in octal. Bash uses readline. Compare the output of `bind -p` on both servers. Inside the troublesome system, does it contain `"\303": self-insert` and `"\251": self-insert`? If not, what if you invoke `bind '"\303": self-insert'` and `bind '"\251": self-insert'`? – Kamil Maciorowski Feb 20 '23 at 16:17
  • @KamilMaciorowski None possesses the lines. If I use `bind` on the faulty system, it gives me `C)`. The other one, it doesn't change anything. – Master DJon Feb 20 '23 at 20:03
  • @KamilMaciorowski I finally found a difference between the systems. Using `bind -v` I saw that the faulty one has `set convert-meta on` and the other `set convert-meta off`. So, I added the **off** one in /etc/inputrc file and boum! Though, there is still a little caveat. Typing `é`, the char appears, but after I can erase two chars with backspace... so I can erase the prompt. – Master DJon Feb 20 '23 at 20:40
  • According to `man 3readline readline` this option is set automatically with respect to the locale. Maybe `en_US.UTF-8` in the troublesome system is not what it should be (a "fake" locale?). I'm not sure how to test this though. – Kamil Maciorowski Feb 20 '23 at 21:20

1 Answers1

3

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
  • 151
  • 9