just a question for my understanding, do you have the issue with the backup plugin only or as well with streaming music from the samba share? Or what is the purpose of the share?
The problem is not the actual permissions, as the Emby users can pretty fine write files, but it is the way how that .NET core function, responsible for creating files, does it. It tries to chmod (not that command, but changing the modes) the file, if the owner does not match, which fails, as the file system/mount itself does not support POSIX permissions. Try chmod on one of those files and you’ll get an error. Of course there is no reason to do it when you create a file as the owner will be automatically that user or, if impossible, the one that owns the mount. So it’s a .NET core bug that has actually been fixed meanwhile, but it takes a while until it reaches through Mono til end-user software.
The symptoms match 100%, but strange is that the user matches in your case. The group however does not. Can you try to change the mount gid so that it matches the primary group of the emby user? groups emby | mawk ‘{print $3}’
My emby user currently looks like this
root@dietpi-server5:/mnt/infrastructure# groups emby | mawk '{print $3}'
emby
root@dietpi-server5:/mnt/infrastructure# id emby
uid=999(emby) gid=995(emby) groups=995(emby),44(video),107(render)
root@dietpi-server5:/mnt/infrastructure#
I had changed the group for emby, thinking that that might be part of the issue. so the fstab does match the emby user perfectly. Should I try a different setting for both user and mount? like change the group back to dietpi (1000)?
So the purpose of the share is two fold. One folder area stores backups of emby, another folder holds the media. I store nfo files and images with the media as I also have kodi clients that use that metadata.
emby cannot currently save anything to folders on that nas share - but emby can read and stream the media without issue. I just tested playback of a tv show, and it worked fine.
Try > chmod > on one of those files and you’ll get an error.
I dont get an error, but the chmod doesnt seem to take effect. The permissions stay as they were before executing the command.
still strange as for me Emby is able to read mp3 files from a samba share. Need to test these backup stuff later the evening
Reading should be no issue, it is only writing that is affected by the bug.
Exactly. I can read files via emby (ie stream them) no problem. Its only when emby needs to write to the share that the issue surfaces.
Is there anything more I can do (to help resolve the bug)?
I’m not quite clear where the bug needs to be fixed. In DietPi or in Emby?
I assumed the issue was with DietPi given that the same version of Emby installed on rasbpian doesnt show the same issue.
Unfortunately I’m not able to test the backup plugin as it needs to be purchased. Somehow it did not allow a trial period, even if I never used emby before 
The same effect can be produced by enabling the nfo metadata saver in the library settings, add some media (or create some dummy files but touching a file that looks like a movie) eg.
touch "Gladiator (2000).mkv"
When emby scans the library, you should see if producing the same error when trying to create “Gladiator (2000).nfo”
Contents of my share look like this when I do. You can see the nfo file is zero-byte.
root@dietpi-server5:/mnt/infrastructure/dummy_data/Movies/Gladiator (2000)# ls -l
total 1024
-rwxrwxrwx 1 emby dietpi 12 Feb 18 15:50 'Gladiator (2000).mkv'
-rwxrwxrwx 1 emby dietpi 0 Feb 19 20:18 'Gladiator (2000).nfo'
When you try to do a backup the same thing happens and you end up with a profile.txt that is zero-byte before the backup process aports.
Did you try it with uid=emby,gid=dietpi? I forgot to mention that we switch the primary group to dietpi.
If it does not help, probably the new beta does: https://github.com/MediaBrowser/Emby.Releases/releases
cd /tmp
wget https://github.com/MediaBrowser/Emby.Releases/releases/download/4.6.0.26/emby-server-deb_4.6.0.26_armhf.deb
dpkg -i emby-server-deb_4.6.0.26_armhf.deb
rm emby-server-deb_4.6.0.26_armhf.deb
Yep. I tried fstab with emby as the user and dietpi as the group (or at least using their ids, rather than their names…assume thats what you mean)
I have also tried both the 4.5.4 and beta of 4.6.0.26. Both show this problem on DietPi, and both have no issue on raspbian.
I meant the names indeed, which are also valid values for those mount options. But it shouldn’t play a role. Since the package does not even pull any dependencies, relies on libc6 only, which is 100% the same on Raspberry Pi OS and DIetPi RPi (both use the same Raspbian repository), there is no difference.
Just to rule it out, could you try to remove the Emby user and reinstall the Emby package (which re-creates the user)? userdel emby
[hr]I tried to replicate, but sadly all uploads, images and song meta data are stored in /var/lib/emby while the actual media files in the Samba share are not touched. Any idea how to trigger the error?
Ah, I enabled nfo saver in the library settings but testing with the example music file only, where editing metadata is not stored in an nfo file. Is there a way to somehow force this?
it can be simulated by using a movie library and create a demo file Gladiator (2000).mkv
I found a similar case on emby board. https://emby.media/community/index.php?/topic/83565-linux-noob-help-with-setting-up-nas-access/
No real solution, the user switched to local HDD at the end
I found another switch to store art files into the library. And now I also see that Metadata is not stored. Strangely no error is thrown, nothing in the logs as well, but re-opening the files meta data shows that changes are not preserved.
Ah I’ll try it with a dummy file.
Okay, very strange now is that it works perfectly fine here, even that the mount owner is dietpi and not changed to emby:
/mnt/samba/Video# l
total 2.0M
-rwxrwx--- 1 dietpi dietpi 270K Feb 19 22:34 'Gladiator (2000)-poster.jpg'
-rwxrwx--- 1 dietpi dietpi 0 Feb 19 22:31 'Gladiator (2000).mkv'
-rwxrwx--- 1 dietpi dietpi 5.8K Feb 19 22:34 'Gladiator (2000).nfo'
Although I have to admit that the Samba server is on the same machine, but Emby has has the mount point added as library directory, so it shouldn’t make a difference.
Are you using a beta version of DietPi?
MichaIng
What SBC you are using?
On VM, not SBC. The DietPi version plays no role here, it’s Debian Buster with up-to-date APT packages.
fstab entry:
//127.0.0.1/dietpi /mnt/samba cifs username=dietpi,password=dietpi,iocharset=utf8,uid=dietpi,gid=dietpi,file_mode=0770,dir_mode=0770,vers=3.1.1,_netdev,nofail,noauto,x-systemd.automount
I’ll retry on RPi.
probably it’s 32 vs 64 bit? or ARM vs x68?