Accessing cifs share filenames with umlauts

Docker Desktop for Windows
#1

Hi all,

I’m having the following problem:

I have a script that uses rsync to fetch files from a remote server and writes it to a cifs share (WD NAS). I used to use this for years on an Ubuntu Laptop. Now I wanted to move this into a docker container on my Windows 10 machine.

Now everything is working as before (almost everything)

The problem is, that now files with umlauts in the filename (I have no control over what files/filenames will be there to rsync) - these are garbled and cannot be read i.e. by tar.

On the ubuntu laptop I have this entry in the fstab:
//{NAS-IP-ADDRESS}/{sharename} /media/{mountname} cifs rw,username={myusername},password={mypassword} 0 0

In my docker-compose,yml:

...
services:
...
    volumes:
        - type: volume
          source: myvolume
          target: /media/{mountname}
          volume:
            nocopy: true

volumes:
    myvolume:
        driver_opts:
            type: cifs
            o: username={myusername},password={mypassword},uid=0,vers=3.0
            device: "//{NAS-IP-ADDRESS}/{sharename}"

what am I missing? I tried to add iocharset=iso8859-15, iocharset=iso8859-15 and iocharset=utf8 to the o: line - all to no avail - nothing changed

I also tried to connect via nfs - same result :frowning:

Any ideas?

I’m thankful for all suggestions to solve this problem.

#2

OK after a couple of more fruitless testing and googling, I finally got it fixed:

first of all it seems I had to explicitly install locales and configure it to (in my case de_DE.UTF-8 - but en_US.UTF-8 will probably do, too)

AND

I had to add iocharset=utf8

AND!!!

I had to explicitly remove all created volumes from within Docker-Desktop as it seemed that docker compose build did NOT recreate the volume just because I changed/added/removed the iocharset parameter… which indeed I would consider a BUG…

Anyway, I hope that this might help somebody to save a couple of hours of searching for a solution…

Cheers

1 Like
#3

Great that you have been able to track down the issue.

Volume configurations are immutable, regardless wether they are created from the cli or docker-compose.