Joulinar
I did see that thread in my troubleshooting, but they seemed to have more systemic issues in getting the drive mounted at all, let alone have emby use it as a target for scraping. I seem to be fine at a CIFS/OS level.
MichaIng
I just tried removing the emby user and reinstalling emby-server. Made no difference.
I read on another thread (actually the same thread Joulinar found) that it needed to be ids rather than names in SMB connection, though I dont know how true that actually is.
just to avoid a misunderstanding, DietPi for Raspberry Pi is a Raspberry OS. DietPi is a set of scripts on top of Raspberry OS, it is not an own OS
Thanks. Good to know.
In that case, for information, I used the dietpi.txt file to install the relevant software on first boot after I image the SD card. Could there be anything relevant in there? Should I share the dietpi.txt I used to build this machine?
The reason I ask…
If DietPi and vanilla Raspberry Pi OS (https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-01-12/2021-01-11-raspios-buster-armhf-lite.zip) are effectively the same thing, and I have no issues with the vanilla install then the only variables are
The DietPi scripts are not involved in running Emby, nor Samba. Only the mount options are created by dietpi-drive_manager but can be manually changed. dietpi.txt options as well do not effect anything related, at least nothing I can imagine in any way.
I now was able to replicate the issue on RPi when mounting the Samba share from the VM. The other way round, mounting the Samba share from RPi on the VM, works. So indeed it seems to be a kernel or architecture related issue. Interesting that the symptoms are so very similar to the .NET core issue.
When vanilla Raspberry Pi OS works, did you try it after upgrading all APT packages, especially the kernel?
ok indeed on a Debian / DietPi VM this is working without issues. So it is Raspberry OS
feardamhan
if you use Raspberry OS, did you update all packages before installation of Emby?
Lol, parallel posts with the same idea 
.
Another question: Where is the Samba server located, actually? Is it a Windows machine or another Linux? Worth to check the Samba server logs.
I’m testing on Synology NAS, always same share where VM is working, RPi not
No. I didnt. I just pulled down the latest image, imaged it to the SD Card, booted and just installed cifs utils and emby on top. so there could well be updates that get pulled down for that that would cause the same issue.
this would make a lot of sense…given that dietpi does these updates automatically during install, and that an update caused me these issues in the first place.
I can try that tomorrow for sure, if you see value - thought perhaps it would prove nothing further than you have already proved.
Jep, indeed it sounds promising and when we identify the package, likely the kernel, it can be downgraded and the issue reported to RPi developers.
will play with RPi kernel now
it is the kernel. Downgrading to 5.4.79 and it is working again
The other way around and updating to 5.10.16 will still give the error
You are making me very happy here. So good to find out I was not going mad (and that I didnt in fact mess up permissions somehow!) 
if needed you can downgrade as follow
sudo rpi-update 0642816ed05d31fb37fc8fbbba9e1774b475113f
Okay, let’s report this to the Emby first, as they will probably be able to know better which kernel feature is actually used/responsible. If then something can be fixed kernel-wise, it can be forwarded to RPi devs: https://github.com/MediaBrowser/Emby/issues
Is that something I should do? Or you guys do?
issue has been introduced on 5.10.
It is working well on 5.4.83 but failing on next version 5.10.0
Issue reported: https://github.com/MediaBrowser/Emby/issues/3676
I’ll also test on Debian Bullseye VM with Linux 5.10 tomorrow, to check if it’s an upstream issue. And Armbian 5.10 kernel.
Magic. Thanks folks!
Can confirm that after downgrading the kernel on my machine its working as expected.