Hi Folks
Have been troubleshooting a problem that arose in the last few days on one of my dietpi installs immediately after running apt upgrade which resulted in emby-server being unable to write files to a mounted nas share (over CIFS). Was working perfectly up to the updated
Have already trashed the system and reinstalled to rule stuff out, and still having the problem.
Would like to do back to the original dietpi image I first used to setup this machine to rule out something that changes along the way. I have the 6.28 image I used.
Is there anyway I can prevent the system from auto-updating to 6.34.3 (and any associated apt upgrades) as part of the install process? I cant find a clean way to revery to 6.28 to test my theories, as it keeps updating as part of the first boot process.
Any tips?
Hi,
usually there is no way to downgrade to a lover version.
Maybe MichaIng can share a way how to prevent the initial update.
It would be much more productive when we helped to investigate the issue why Emby cannot write to the CIFS share. Sounds like a permission issue, and probably others suffer as well from it while we might be able to implement a workaround of fix right into DietPi. Blocking system and security upgrades for the whole server only because of a single issue really is not something I’m keen helping with, where other users might copy&paste the same, causing just a bunch of other issues that are fixed already with current DietPi and APT packages 
.
And did you try to reinstall Emby? Probably the newest version and refreshing group permissions solves the issue: dietpi-software reinstall 41
Thanks for the replies
I’m all for getting to the bottom of the issue! I’m not a fan of staying on old versions either.
It’s not permissions. I’m confident I’ve proven that beyond a doubt. Can share details of tests I’ve run if you want.
I did try the upgrade of emby. Didn’t fix the issue.
I also tried a Raspberry Pi OS install with the same versions of emby (old and updated) and that has no problem.
So I feels to me like something in the dietpi update. I can reproduce easily by reinstalling dietpi in the morning (it’s 1am here at the moment).
Once setup I can post any logs and perform any trouble shooting steps you suggest.
Do you want me to go with the version of emby installed by dietpi (4.5.4 I think) or will I go with latest version? I don’t think it matters as both show same symptom and neither have the issue on raspbian.
for testing, you could change the permission the CIFS share is mounted with.
Anyway I did a test installation with DietPi 7.0 Beta on my RPi3B+ 32bit. Emby is working without issues. I could mount my MP3 library from my Synology NAS via CIFS and was able to play music on a Android mobile phone using Emby App
BTW: Emby 4.5.4 is the latest version available according Emby blog https://emby.media/community/index.php?/blogs/blog/1-emby-blog/
So I’m really confident the permissions really are not an issue
- The nas has a user called emby.
- The shared is mounted with a emby.
- The file permissions are owned by emby and set to 777
- When logged in as the emby at command prompt I can add/edit/delete files from the share.
- emby-server is running under emby
there is no issue viewing or playing files, but if I want emby to scrape and save metadata as nfo, its failing with permission denied.
Here is the thread where I have been working with the emby folks. You can see all the permission steps I have tested there as well as the errors encountered by both emby scraping and the emby backup utility
https://emby.media/community/index.php?/topic/95222-emby-user-failing-to-write-to-nas-drive-cifs-permissions-are-fine/
4.5.4 seems to be latest installable via dietpi-software, but there is a 4.6.0.26 beta listed for Armv7 (armhf) which I have also tried.
https://emby.media/linux-server.html
as I said, for me emby is working together with a mounted SAMBA share. I can steam music to my mobile device using emby app
Unless the file names change, DietPi-Software always installs the latest upstream Emby version. To update it, a simple reinstall works: dietpi-software reinstall 41
Our install btw is the official package, nearly unmodified. All we do is adding the emby user to a few more groups so that DRM and media access permissions are guaranteed, so it’s most likely not an issue of Emby but of the CIFS mount options.
Can you show the service log when trying to access the CIFS mount?
journalctl -u emby-server
Oh. I mean to say, re permissions.
Setting up the exact same config ie
- mount point created / owned by same user /group
- fstab using the exact same mount user (string copied and pasted)
- same version of emby
- emby user ID /group config identical
When scraping / attempting config backup via plugin all works flawlessly
With DietPi 6.34.3, emby encounters errors similar to this (this example is from backup. scraping to nfo does the same thing)
*** Error Report ***
Version: 4.5.4.0
Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_armhf.deb
Operating system: Linux version 5.10.11-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1399
Framework: .NET Core 3.1.8
OS/Process: arm/arm
Runtime: opt/emby-server/system/System.Private.CoreLib.dll
Processor count: 4
Data path: /var/lib/emby
Application path: /opt/emby-server/system
System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path '/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-17 23.10.0 - Auto/profile.txt' is denied.
---> System.IO.IOException: Permission denied
--- End of inner exception stack trace ---
at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
at System.IO.FileStream.FlushWriteBuffer()
at System.IO.FileStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at System.IO.StreamWriter.CloseStreamFromDispose(Boolean disposing)
at System.IO.StreamWriter.Dispose(Boolean disposing)
at System.IO.TextWriter.Dispose()
at System.IO.File.WriteAllText(String path, String contents)
at Emby.Server.Implementations.IO.ManagedFileSystem.WriteAllText(String path, String text)
at MBBackup.ServerEntryPoint.ExecuteBackup(BackupProfile settings, CancellationToken cancellationToken, IProgress`1 progress, Boolean isAuto)
at MBBackup.Entities.ScheduledBackupTask.Execute(CancellationToken cancellationToken, IProgress`1 progress)
at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.ExecuteInternal(TaskOptions options)
Source: System.Private.CoreLib
TargetSite: Void WriteNative(System.ReadOnlySpan`1[System.Byte])
InnerException: System.IO.IOException: Permission denied
Source:
well it is a permission issue
Access to the path '/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-17 23.10.0 - Auto/profile.txt' is denied.
usually DietPi use /mnt to mount shares
I get that thats what it says. But something is mis-reporting here I think.
Take a look at operations, carried out as the emby user on the command line
emby@dietpi-server5:/mount/infrastructure/emby_config $ ls
backups linux test
emby@dietpi-server5:/mount/infrastructure/emby_config $ cd test/
emby@dietpi-server5:/mount/infrastructure/emby_config/test $ ls -l
total 0
drwxrwxrwx 2 emby users 0 Feb 17 17:22 'Emby Backup - 2021-02-17 17.22.57 - Auto'
drwxrwxrwx 2 emby users 0 Feb 17 22:57 'Emby Backup - 2021-02-17 22.57.7 - Auto'
drwxrwxrwx 2 emby users 0 Feb 17 23:10 'Emby Backup - 2021-02-17 23.10.0 - Auto'
drwxrwxrwx 2 emby users 0 Feb 18 09:25 'Emby Backup - 2021-02-18 09.25.24 - Auto'
emby@dietpi-server5:/mount/infrastructure/emby_config/test $ touch test.txt
emby@dietpi-server5:/mount/infrastructure/emby_config/test $ ls -l
total 0
drwxrwxrwx 2 emby users 0 Feb 17 17:22 'Emby Backup - 2021-02-17 17.22.57 - Auto'
drwxrwxrwx 2 emby users 0 Feb 17 22:57 'Emby Backup - 2021-02-17 22.57.7 - Auto'
drwxrwxrwx 2 emby users 0 Feb 17 23:10 'Emby Backup - 2021-02-17 23.10.0 - Auto'
drwxrwxrwx 2 emby users 0 Feb 18 09:25 'Emby Backup - 2021-02-18 09.25.24 - Auto'
-rwxrwxrwx 1 emby users 0 Feb 18 09:29 test.txt
emby@dietpi-server5:/mount/infrastructure/emby_config/test $ rm test.txt
emby@dietpi-server5:/mount/infrastructure/emby_config/test $ ls -l
total 0
drwxrwxrwx 2 emby users 0 Feb 17 17:22 'Emby Backup - 2021-02-17 17.22.57 - Auto'
drwxrwxrwx 2 emby users 0 Feb 17 22:57 'Emby Backup - 2021-02-17 22.57.7 - Auto'
drwxrwxrwx 2 emby users 0 Feb 17 23:10 'Emby Backup - 2021-02-17 23.10.0 - Auto'
drwxrwxrwx 2 emby users 0 Feb 18 09:25 'Emby Backup - 2021-02-18 09.25.24 - Auto'
drwxrwxrwx 2 emby users 0 Feb 18 09:29 'Emby Backup - 2021-02-18 09.29.15 - Auto'
emby@dietpi-server5:/mount/infrastructure/emby_config/test $ cd 'Emby Backup - 2021-02-18 09.29.15 - Auto'
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 09.29.15 - Auto $ ls -l
total 0
-rwxrwxrwx 1 emby users 0 Feb 18 09:29 profile.txt
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 09.29.15 - Auto $
Plus I can do all the normal cp and mv operations
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 15.52.49 - Auto $ ls -l
total 1024
-rwxrwx--- 1 emby users 12 Feb 18 16:01 profile.txt
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 15.52.49 - Auto $ cp /mount/infrastructure/software/STBEditor_V1.7.2_652HD.exe ./
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 15.52.49 - Auto $ ls -l
total 2048
-rwxrwx--- 1 emby users 12 Feb 18 16:01 profile.txt
-rwxrwx--- 1 emby users 577536 Feb 18 2021 STBEditor_V1.7.2_652HD.exe
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 15.52.49 - Auto $ mv STBEditor_V1.7.2_652HD.exe renamed.exe
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 15.52.49 - Auto $ ls -l
total 2048
-rwxrwx--- 1 emby users 12 Feb 18 16:01 profile.txt
-rwxrwx--- 1 emby users 577536 Feb 18 16:02 renamed.exe
emby@dietpi-server5:/mount/infrastructure/emby_config/test/Emby Backup - 2021-02-18 15.52.49 - Auto $
Is DietPi doing any sandboxing that could be effecting things?
As I say…the permissions / config are identical between DietPi and Raspbian installations. Only the DietPi install is having this issue. So between all the manual permissions tests and the tests across different OSs it feels like its not a permissions issue at a user level but perhaps some kind of restriction around the emby-server process itself.
I dont proclaim to know much (nearly nothing actually) about sandboxing, but I know it does put an additional layer of restrictions around the process right?
Ohhh, I forget that Emby is as well .NET/mono-based. The bug is pretty sure this one: https://github.com/MichaIng/DietPi/issues/3529
If it worked before, then probably Emby has updated internal libraries to Mono v6 or the related .NET core version that introduced the issue.
The only workaround is to mount the CIFS share with the emby user itself: In /etc/fstab change uid=dietpi of the CIFS mount to uid=emby.
That sounds similar. Unfortunately, my fstab entry already looks like this
//xxx.xxx.xxx.xxx/Infrastructure /mount/infrastructure cifs username=emby,password=emby,iocharset=utf8,uid=999,gid=995,file_mode=0770,vers=3.1.1,_netdev,nofail,noauto,x-systemd.automount
the uid of 999 and gid of 995 corresponds to emby user and group respectively
I will add that this was all working before, with uid=1000 (ie dietpi) in the fstab…its only very recently with an update that its stopped working.
Ah okay sorry you posts above that already. Just to rule it out: file_mode=0777 doesn’t solve it either, does it?
Is DietPi doing any sandboxing that could be effecting things?
Not in case of Emby.
Since services sometimes come with strict internal hardenings, could you try to change the mount point to /mnt/infrastructure?
Also, please paste the systemd service content: systemctl cat emby-server
root@dietpi-server5:~# systemctl cat emby-server
# /usr/lib/systemd/system/emby-server.service
[Unit]
Description=Emby Server is a personal media server with apps on just about every device.
After=network.target
[Service]
EnvironmentFile=/etc/emby-server.conf
WorkingDirectory=/opt/emby-server
ExecStart=/opt/emby-server/bin/emby-server
RestartForceExitStatus=3
User=emby
[Install]
WantedBy=multi-user.target
Okay, the systemd unit is not the issue 
.
Neither 0777 nor /mnt/infrastructure made a different unfortunately
I dont understand how emby can create a folder, and create a zero size file, but not save content to the file
root@dietpi-server5:/mnt/infrastructure/emby_config/test# ls -l
total 0
drwxr-xr-x 2 emby root 0 Feb 18 17:28 'Emby Backup - 2021-02-18 17.28.46 - Auto'
drwxr-xr-x 2 emby root 0 Feb 18 17:34 'Emby Backup - 2021-02-18 17.34.45 - Auto'
drwxr-xr-x 2 emby root 0 Feb 18 17:45 'Emby Backup - 2021-02-18 17.44.56 - Auto'
drwxr-xr-x 2 emby root 0 Feb 18 17:45 'Emby Backup - 2021-02-18 17.45.3 - Auto'
drwxr-xr-x 2 emby root 0 Feb 19 00:10 'Emby Backup - 2021-02-19 00.10.0 - Auto'
drwxr-xr-x 2 emby root 0 Feb 19 12:49 'Emby Backup - 2021-02-19 12.49.37 - Auto'
drwxr-xr-x 2 emby root 0 Feb 19 17:02 'Emby Backup - 2021-02-19 17.2.14 - Auto'
drwxr-xr-x 2 emby root 0 Feb 19 18:28 'Emby Backup - 2021-02-19 18.28.49 - Auto'
drwxr-xr-x 2 emby root 0 Feb 19 18:32 'Emby Backup - 2021-02-19 18.32.32 - Auto'
drwxr-xr-x 2 emby root 0 Feb 19 18:34 'Emby Backup - 2021-02-19 18.34.26 - Auto'
root@dietpi-server5:/mnt/infrastructure/emby_config/test# cd Emby\ Backup\ -\ 2021-02-19\ 18.34.26\ -\ Auto/
root@dietpi-server5:/mnt/infrastructure/emby_config/test/Emby Backup - 2021-02-19 18.34.26 - Auto# ls -l
total 0
-rwxrwxrwx 1 emby root 0 Feb 19 18:34 profile.txt
root@dietpi-server5:/mnt/infrastructure/emby_config/test/Emby Backup - 2021-02-19 18.34.26 - Auto#
All these folders are auto created by the backup plugin.