[BUG] UTF8 normalization fails on Unraid zpool

[saaaauce]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When files that require UTF8 normalization are added to a shared folder on the Unraid server side, the normalization process fails with the message Error renaming "[...].extension.tmp" to "[...].extension" while normalizating UTF8 encoding: file does not exist. You will want to rename this file back manually and they are left with .tmp extensions.
After manually deleting the .tmp files and copying the original files into the folder again, the error message changes to normalizing path: item has UTF8 encoding conflict with another item.

Expected Behavior

The UTF8 normalization should proceed normally

Steps To Reproduce

1: Running syncthing installed via the linuxserver Unraid community app with default settings. The host folder /mnt/user/media is mapped to the container folder /media. The host folder is placed on a 4-disk zpool with the path /mnt/pool/media.
2: Create a shared folder, i.e. /media/Test. The type of folder (send/receive or receive only) appears irrelevant.
3: Add files to the folder that need UTF8 normalization. In this case, SMB was used (media folder mapped as a network drive in Windows).
4: Wait for the new files to get picked up or trigger a manual rescan.
5: UTF normalization fails, .tmp files are left in the directory.

Environment

- OS: Unraid 6.12.10
- How docker service was installed: Built-in

CPU architecture

x86-64

Docker creation

docker run
  -d
  --name='syncthing'
  --net='proxynet'
  -e TZ="Europe/Berlin"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Ariake"
  -e HOST_CONTAINERNAME="syncthing"
  -e 'PUID'='99'
  -e 'PGID'='100'
  -e 'UMASK'='022'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8384]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/syncthing-logo.png'
  -p '8384:8384/tcp'
  -p '22000:22000/tcp'
  -p '22000:22000/udp'
  -p '21027:21027/udp'
  -v '/mnt/user/media/':'/media':'rw'
  -v '/mnt/user/appdata/syncthing':'/config':'rw' 'lscr.io/linuxserver/syncthing'

Container logs

[6JV4N] 2024/04/27 17:30:12 INFO: Adding folder "Test" (2wnyl-fub3e)
[6JV4N] 2024/04/27 17:30:12 INFO: No stored folder metadata for "2wnyl-fub3e"; recalculating
[6JV4N] 2024/04/27 17:30:12 INFO: Ready to synchronize "Test" (2wnyl-fub3e) (sendreceive)
[6JV4N] 2024/04/27 17:30:12 INFO: Completed initial scan of sendreceive folder "Test" (2wnyl-fub3e)
[6JV4N] 2024/04/27 17:30:41 INFO: Ready to synchronize "Test" (2wnyl-fub3e) (receiveonly)
[6JV4N] 2024/04/27 17:30:41 INFO: Restarted folder "Test" (2wnyl-fub3e) (receiveonly)
[6JV4N] 2024/04/27 17:30:41 INFO: Completed initial scan of receiveonly folder "Test" (2wnyl-fub3e)
[6JV4N] 2024/04/27 17:30:53 WARNING: Error renaming "アンデッド・ダンスロック(Dark Acid Mix).wav.tmp" to "アンデッド・ダンスロック(Dark Acid Mix).wav" while normalizating UTF8 encoding: file does not exist. You will want to rename this file back manually
[6JV4N] 2024/04/27 17:30:53 WARNING: Error renaming "ビードロ模様(droplamp 2022 Remix).mp3.tmp" to "ビードロ模様(droplamp 2022 Remix).mp3" while normalizating UTF8 encoding: file does not exist. You will want to rename this file back manually
[6JV4N] 2024/04/27 17:36:39 INFO: Scanner (folder "Test" (2wnyl-fub3e), item "アンデッド・ダンスロック(Dark Acid Mix).wav"): normalizing path: item has UTF8 encoding conflict with another item
[6JV4N] 2024/04/27 17:36:39 INFO: Scanner (folder "Test" (2wnyl-fub3e), item "ビードロ模様(droplamp 2022 Remix).mp3"): normalizing path: item has UTF8 encoding conflict with another item

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[saaaauce]

After some further testing it seems that the issue is caused by Unraid ZFS datasets/shares defaulting to normalization formD. It does not occur on another dataset manually created with formC.
Nevermind, I made a mistake in the creation of the dataset. The issue also occurs when using formC.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue is locked due to inactivity