mount -t cifs -o user=user1 //1.1.1.1/test, Tüst /mnt/test3/
I can not realy see here what you think this should do. In any case, bash will split this into the following “words”:
mount
-t
cifs
-o
user=user1
//1.1.1/test,
Tüst
/mnt/test3/
When you do not want one of those spaces interpreted by the shell, you must excape it e.g.
mount -t cifs -o user=user1 //1.1.1.1/test,\ Tüst /mnt/test3/
or
mount -t cifs -o user=user1 '//1.1.1.1/test, Tüst' /mnt/test3/
The field ‘//1.1.1.1/test, Tüst’ will be used (without the quotes) by mount as the definition of the device. If that is a valid definition I do not know (never used cifs). In any case the ü should normaly not be a problem if on the system 1.1.1.1 UTF-8 encoded Unicode is used like on this system.
BTW your octal representation of the ü as \201 is incorrect imho. The bytes (in octal are):
henk@boven:~> echo ü | od
0000000 136303 000012
0000003
henk@boven:~>
This gives (after exchanging the bytes and cutting off the CR) \303 \136 for UTF-8 encoded Unicode.
i tried your suggestions, but unfortunately neither of them gave me the expected result.
In the meanwhile i learned that i have to put phrases with spaces in quotation marks, because escaping with slash or backslash is not allowed in cifs?!?
I tried this with another directory
mount -t cifs -o user=user1 //1.1.1.1/"Tüst test" /mnt/test3/
and it did mount!
But if i try to put my first directory in quotation marks
mount -t cifs -o user=user1 //1.1.1.1/"test, Tüst" /mnt/test3/
it does NOT mount.
So my conclusion:
spaces and umlauts in quotation marks are no problem.
the only difference between example one and two is the comma in example two. So i believe the comma is the last problem.
If anyone has experience in this very special case, you’re welcome.
While your last conclusion (the , is the culprit) might be correct, the rest of what you say shows imho that you do not understand complete what the quoting does.
The quoting has nothing to do with cifs. You are typing your command in the shell (bash) and thus the first program that interpretes what you type is bash. And a blank space is a special character in bash. Thus, when you do NOT want bash to treat this as a special character, but wants that blanks space be part of the argument given to mount, you must escape it in the way bash prescribes.
And that it what I showed you. It has nothing to do with mount neither with cifs. It is purely bash.
While your way of escaping (not using one of the two suggestions I gave you) works also in bash, I hope you undestand why it works the same as the suggestions I gave.
Then we come to mount. Mount gets as argument
//1.1.1.1/test, Tüst
and will this interprete (after parsing the arguments before it) as the device. When I understand you correctly, the //1.1.1.1/ part is correct, because when you use a different directory name, the mount does what you expect.
The second part of that argument should be used as a directory (that directory of course must exist in the cifs server, you did not prove that btw). As you have tested, using a name without a , in it works as expected. I have no idea if that , is already giving troubles while it is parsed by mount, or if the troubles arises in the server software. You could try to check the logging of the server to see if it gives any error messages.
BTW, I re-read your first post. And what I should have done of course is asking you to post the complete information: the prompt, the command, the output and the next prompt. Just saying “without success” contains almost no information for those who might try to help you.