MichaIng
It’s happen on my Bullseye VM as well. Means it’s an issue upstream with kernel 5.10
Got some answer: https://github.com/MediaBrowser/Emby/issues/3676
When still struggling with the issue, please try to add the nobrl mount option to the CIFS mount in /etc/fstab. The mount seems to be still required to be owned by the emby user, as the same issue that Sonarr/Radarr etc suffered from seems to be true here as well, but that’s not the only one. Alternatively, forcemand could be tested. It’s some kind of file locking mechanism in the CIFS protocol, and there is a Windows style “mandatory byte range locking” and a POSIX style “advisory byte range locking” and I have the impression that with Linux 5.10 the CIFS (mount) driver switch from the first to the second, which probably causes issues with .NET core, or so. nobrl (=no byte range locking) disables this locking completely, which seems to solve the issue, but may imply some issues when concurrent writes to the server are done (which is usually what locking aims to prevent). forcemand (=force mandatory byte range locking) forces Windows style mandatory byte range locking, so the old style locking, which according to the CIFS mount man page is “for some (presumably rare) applications, originally coded for DOS/Windows, which require Windows style mandatory byte range locking”, which sounds pretty well like .NET core falls under that category 
.