[Bug]: Audiobookshelf errors when scanning titles containing an apostrophe in Windows share #1839

Closed
opened 2026-04-24 23:59:35 +02:00 by adam · 5 comments
Owner

Originally created by @petenun on GitHub (Mar 24, 2024).

Describe the issue

I'm running ABS within a linux-based (Windows WSL2, Ubuntu) docker container with a library pointing to a cifs Volume mapped to a Windows share containing audiobook files. Upon scanning M4B titles within the library, about half my books are missing due to the Windows filenames containing an apostrophe (eg Hitchhiker's Guide to the Galaxy). My share is hosted on a very large (72TB) physical file server running Windows Server 2019. Error logs show No such file or directory with apostrophe's shown as question marks in the path.

image

Steps to reproduce the issue

  1. Configure docker container with cifs volume pointing to a Windows share
  2. Scan library containing folders or files containing an apostrophe
  3. Check the logs to see the errors.
  4. Note the titles missing from the scanned library

Audiobookshelf version

2.8.1

How are you running audiobookshelf?

Docker

Originally created by @petenun on GitHub (Mar 24, 2024). ### Describe the issue I'm running ABS within a linux-based (Windows WSL2, Ubuntu) docker container with a library pointing to a cifs Volume mapped to a Windows share containing audiobook files. Upon scanning M4B titles within the library, about half my books are missing due to the Windows filenames containing an apostrophe (eg Hitchhiker's Guide to the Galaxy). My share is hosted on a very large (72TB) physical file server running Windows Server 2019. Error logs show No such file or directory with apostrophe's shown as question marks in the path. ![image](https://github.com/advplyr/audiobookshelf/assets/55004359/2ca874b8-d81a-4e26-803e-6f60a3e5f34f) ### Steps to reproduce the issue 1. Configure docker container with cifs volume pointing to a Windows share 2. Scan library containing folders or files containing an apostrophe 3. Check the logs to see the errors. 4. Note the titles missing from the scanned library ### Audiobookshelf version 2.8.1 ### How are you running audiobookshelf? Docker
adam added the bug label 2026-04-24 23:59:35 +02:00
adam closed this issue 2026-04-24 23:59:37 +02:00
Author
Owner

@advplyr commented on GitHub (Mar 24, 2024):

Are you using an ASCII apostrophe?

@advplyr commented on GitHub (Mar 24, 2024): Are you using an ASCII apostrophe?
Author
Owner

@petenun commented on GitHub (Mar 24, 2024):

It's a standard Windows NTFS file system, so I believe it's a unicode character set. I believe standard ASCII is a subset of unicode.

@petenun commented on GitHub (Mar 24, 2024): It's a standard Windows NTFS file system, so I believe it's a unicode character set. I believe standard ASCII is a subset of unicode.
Author
Owner

@DavidPesticcio commented on GitHub (Mar 30, 2024):

It's curious that the apostrophe is being represented by a question mark in the logs - is this an ABS thing, or does it appear like that when you do an ls of the file from the Linux shell.

Are you able to confirm in the Linux shell using the below command, or by simply doing an ls on the file itself?

The below line when run in a Linux shell will result in the decimal value of 65.

(export CHARACTER="A" LC_CTYPE=C; printf '%d\n' "'$CHARACTER")

Copy the line above and paste it to your WSL Linux shell prompt.

Copy the apostrophe character from the filename in question from Windows Explorer, paste it in place of the letter A in the variable CHARACTER above.

If your apostrophe is an ASCII apostrophe it will result in the decimal value of 39.

There are variations of characters that can look like an apostrophe - if you did not type the name of the file and you copied and pasted it, or if the file was provided to you from elsewhere, then the character may not actually be the ASCII version of the apostrophe that you expect.

See also:
https://en.wikipedia.org/wiki/Apostrophe#Characters_similar_to_apostrophe

HTH 😃

@DavidPesticcio commented on GitHub (Mar 30, 2024): It's curious that the apostrophe is being represented by a question mark in the logs - is this an ABS thing, or does it appear like that when you do an `ls` of the file from the Linux shell. Are you able to confirm in the Linux shell using the below command, or by simply doing an `ls` on the file itself? The below line when run in a Linux shell will result in the decimal value of 65. ``` (export CHARACTER="A" LC_CTYPE=C; printf '%d\n' "'$CHARACTER") ``` Copy the line above and paste it to your WSL Linux shell prompt. Copy the apostrophe character from the filename in question from Windows Explorer, paste it in place of the letter `A` in the variable `CHARACTER` above. If your apostrophe is an ASCII apostrophe it will result in the decimal value of 39. There are variations of characters that can look like an apostrophe - if you did not type the name of the file and you copied and pasted it, or if the file was provided to you from elsewhere, then the character may not actually be the ASCII version of the apostrophe that you expect. See also: https://en.wikipedia.org/wiki/Apostrophe#Characters_similar_to_apostrophe HTH :smiley:
Author
Owner

@petenun commented on GitHub (Mar 31, 2024):

Here are my results:

(export CHARACTER="A" LC_CTYPE=C; printf '%d\n' "'$CHARACTER")
65

(export CHARACTER="'" LC_CTYPE=C; printf '%d\n' "'$CHARACTER")
39

Keep in mind that this is a standard Windows character set, the most commonly-used one on the planet, so it's not exactly an exception. [No slight intended to Mac or Linux users. I'm not a Windows fanboy, but that doesn't mean it's not the most common desktop OS.]

@petenun commented on GitHub (Mar 31, 2024): Here are my results: (export CHARACTER="A" LC_CTYPE=C; printf '%d\n' "'$CHARACTER") 65 (export CHARACTER="'" LC_CTYPE=C; printf '%d\n' "'$CHARACTER") 39 Keep in mind that this is a standard Windows character set, the most commonly-used one on the planet, so it's not exactly an exception. [No slight intended to Mac or Linux users. I'm not a Windows fanboy, but that doesn't mean it's not the most common desktop OS.]
Author
Owner

@DavidPesticcio commented on GitHub (Mar 31, 2024):

Okay, so it seems that the character on the Windows side is actually an apostrophe. 👍

To rule out any translation that may be going on, where you are referencing the /audiobooks volume, was the apostrophe taken from the windows server (over RDP etc) or directly from the share on the windows host that accesses the share exported from the windows server, i.e. the host running ABS?

I presume you are sharing from the windows server to the windows host as a drive letter, then accessing the share via the mapped WSL path in the docker-compose.yml file, so something like;

    volumes:
    - /mnt/c/audiobooks:/audiobooks

I'm wondering why does ABS would show the apostrophe as a question mark in the logs... I don't know the answer to that, but perhaps it's intentional, or an escaping issue in ABS or a filesystem presentation issue with the windows share somehow because WSL is doing something behind the scenes.

Can you run ls with the full path to the respective Jacqueline Carey directory location;

  1. from outside the ABS container at the WSL prompt
  2. from within the ABS container

If there is no question mark in the output when running ls in either point 1 or 2, then the problem is likely to be ABS, but if there is a question mark in either or both places, then it likely relates to how the share is configured.

Is it possible for you to provide the contents of the docker-compose.yml file, to see what you have in the volumes section?

Thanks.

@DavidPesticcio commented on GitHub (Mar 31, 2024): Okay, so it seems that the character on the Windows side is actually an apostrophe. :+1: To rule out any translation that may be going on, where you are referencing the `/audiobooks` volume, was the apostrophe taken from the windows server (over RDP etc) or directly from the share on the windows host that accesses the share exported from the windows server, i.e. the host running ABS? I presume you are sharing from the windows server to the windows host as a drive letter, then accessing the share via the mapped WSL path in the `docker-compose.yml` file, so something like; ``` volumes: - /mnt/c/audiobooks:/audiobooks ``` I'm wondering why does ABS would show the apostrophe as a question mark in the logs... I don't know the answer to that, but perhaps it's intentional, or an escaping issue in ABS or a filesystem presentation issue with the windows share somehow because WSL is doing something behind the scenes. Can you run `ls` with the full path to the respective `Jacqueline Carey` directory location; 1. from outside the ABS container at the WSL prompt 2. from within the ABS container If there is no question mark in the output when running `ls` in either point 1 or 2, then the problem is likely to be ABS, but if there is a question mark in either or both places, then it likely relates to how the share is configured. Is it possible for you to provide the contents of the `docker-compose.yml` file, to see what you have in the volumes section? Thanks.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1839