Closed J-ohn closed 2 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Hi, I have a simular issue with German umlaute (üäöß). I'm usinf the current 1.14.0 SMB csi driver in the latest k3s cluster.
Any ideas how to fix this?
regards André
In bash:
$ echo '$'\317\203\317\207\316\265\316\264\316\271\316\277'''$'\317\207\317\211\317\201\316\271\317\202'''$'\317\204\316\271\317\204\316\273\316\277''_-_2022-03-12t100557_115.png'
σχεδιοχωριςτιτλο_-_2022-03-12t100557_115.png
So the filenames exposed by cifs
are valid UTF-8 strings. The problem is probably with your application which is expecting a different encoding for filenames. It's not a problem with csi-driver-smb
.
Try setting the environment variable LC_CTYPE=C.UTF-8
and see if it helps. If so then you could bake that environment variable into your container image to make it the default.
What happened: 1) Mounted a share with files whose names contain greek characters (tried both with a vm running windows as the smb server and an azure files storage as the smb server) 2) Attached to the pod and did an ls on the share 3) The file names had question marks instead of the greek characters e.g. ????? ??.JPG What you expected to happen: Comparing to the behavior of the azureFile csi driver and running the same test the files listed using ls in linux we got file names like so ''$'\317\203\317\207\316\265\316\264\316\271\316\277'''$'\317\207\317\211\317\201\316\271\317\202'''$'\317\204\316\271\317\204\316\273\316\277''_-_2022-03-12t100557_115.png' which in turn are interpreted correctly by the application. If you create a file with greek characters from the application under the mounted folder, the file is correctly shown with ls (with escaped characters like the above) and listed by the application, but if you visit either the windows server or azure storage and see how it shows the filename you get something like this ÏÏεδιο_ÏÏÏιÏÏιÏλο-_2022-03-12t100557115.png How to reproduce it: 1) attach to a running pod with a mount on it 2) cd to your mounted directory 3) touch ''$'\317\203\317\207\316\265\316\264\316\271\316\277'''$'\317\207\317\211\317\201\316\271\317\202''_'$'\317\204\316\271\317\204\316\273\316\277''.png' 4) visit the mount from the storage's side (azure storage explorer for example), instead of seeing a file name like so "σχεδιο_χωρις_τιτλο.png" you will see an ineligible file name Anything else we need to know?:
Environment:
kubectl version
): 1.27.8uname -a
): Linux web-1 5.15.0-89-generic #99-Ubuntu SMP Mon Oct 30 20:42:41 UTC 2023 x86_64 GNU/Linux