Editing metadata does not update nfo file

[nuentes 41]

I just migrated hard drives to a different VM and rebuilt my library. I've found that metadata that I manually changed for certain shows did not update the nfo files that are placed in the media folders. Meaning there are now a lot of manual changes that I made that are now lost. Is this expected behavior?

[Luke 42078]

Hi, did you enable saving metadata to nfo files in your library settings?

[nuentes 41]

Yes, I've had that enabled for this Library the entire time. Emby actually originally created these nfo files.

I also just confirmed that the emby user is in the group that owns (and has r/w permission) to the nfo files

Edited July 26, 2020 by nuentes

[nuentes 41]

I just checked the logs, and this is indeed a permissions issue.

 

System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path '/mnt/2TB_1/Completed/Youtube/[redacted].nfo' is denied.
---> System.IO.IOException: Permission denied
--- End of inner exception stack trace ---
at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileStream(String path, FileOpenMode mode, FileAccessMode access, FileShareMode share, FileOpenOptions fileOpenOptions)
at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileStream(String path, FileOpenMode mode, FileAccessMode access, FileShareMode share, Boolean isAsync)
at NfoMetadata.Savers.BaseNfoSaver.SaveToFile(Stream stream, String path)
at NfoMetadata.Savers.BaseNfoSaver.Save(BaseItem item, CancellationToken cancellationToken)
at MediaBrowser.Providers.Manager.ProviderManager.SaveMetadata(BaseItem item, LibraryOptions libraryOptions, ItemUpdateType updateType, IMetadataSaver[] savers, CancellationToken cancellationToken)
Source: System.Private.CoreLib
TargetSite: Void ThrowExceptionForIoErrno(ErrorInfo, System.String, Boolean, System.Func`2[Interop+ErrorInfo,Interop+ErrorInfo])
InnerException: System.IO.IOException: Permission denied
Source:
TargetSite:

I just went into OMV and for all shared paths, I updated the user/group permissions for all files/directories to myuser:myuser, with rw access for both user and group.

Emby is in the following groups: emby video render myuser

I am able to create/modify files on the host system just fine. Emby for some reason cannot write, only read from the shares

[Luke 42078]

OK yes there you go. So you just need to ensure that Emby server has write access to the location and then it should be able to save the nfo file.

[nuentes 41]

I'm sorry, but I don't know what I'm missing. The user is in a group that has read/write access. Am I not understanding something about how NFS permissions work? When I check the permissions on the emby-host server, I can see that the correct user/group has read/write access. Best I can think of is to change the user that emby runs with, but I don't think that's really a suggested route.

[Luke 42078]

Yea at a glance it looks ok but as this is specific to your environment its hard to say. @mastrmind11 may have some tips.

[mastrmind11 722]

well let's start by looking at what the output of ls -l is from each of the folders in the path above, starting with /mnt an working down.

Edited July 27, 2020 by mastrmind11

[nuentes 41]

So I thought you had just cracked it, because I had neglected to look at the permissions of the root of /mnt/. I've corrected them, and now things appear to be worse, as emby can't even read some of the directories now. Here's what I'm getting now

andre@NAS:/mnt$ ls -l
total 16
drwxrws---  9 andre andre 4096 Jul 20 14:11 12TB_1
drwxrwsr-x 14 andre andre 4096 Jul 26 17:56 2TB_1
drwxrwsr-x  5 andre andre 4096 Jul 25 10:43 8TB_1
drwxrws---  7 andre andre 4096 Jul 24 12:52 8TB_2
andre@NAS:/mnt$ cd 12TB_1
andre@NAS:/mnt/12TB_1$ ls -l
total 88
drwxrwxr-x  13 andre andre  4096 Jun  8 17:10 'Don Hertzfeldt'
drwxrwxr-x   5 andre andre  4096 Jul 25 15:29  Jess_Movies
drwx------   2 root  root  16384 Jul 17 09:56  lost+found
drwxrwxr-x 580 andre andre 32768 Jul 25 15:29  Movies_Archive
drwxrwxr-x 520 andre andre 28672 Jul 25 17:18  Movies_New
drwxrwxr-x  46 andre andre  4096 Jun 10 07:49  Rifftrax
andre@NAS:/mnt$ cd Movies_New
andre@NAS:/mnt/12TB_1/Movies_New$ ls -l

there are too many to list here, but they all have the same permissions:

drwxrwxr-x 2 andre andre 4096 Jun

Traversing into individual folders is a similar result. Below is a representation of what all the folders look like:

-rwxrwxr-x 1 andre andre     503392 Apr 12 21:45 fanart.jpg
-rwxrwxr-x 1 andre andre     410695 Apr 18 14:03 landscape.jpg
-rwxrwxr-x 1 andre andre      34612 Apr 18 20:42 logo.png
-rwxrwxr-x 1 andre andre     120743 Apr 18 20:42 poster.jpg
-rwxrwxr-x 1 andre andre 4362262528 Nov  3  2015 video file

As I said in the beginning, I started by adjusting the permissions for the root of /mnt/. Most of the contents of that folder had permissions similar to this (sorry, I didn't actually save the output):

drwxr-x--- andre users

 

[nuentes 41]

I believe I just resolved this. I had not set a squash rule in the NFS shares, so they were using the default setting of "no_all_squash". I added the following:

all_squash,anonuid=1000,anongid=1000

This being because andre:andre are both uid and gid 1000 on the emby server. It appears that permissions on NFS don't work quite the way I had imagined. Anyway, after adding this, it appears that Emby is again able to save and modify nfo files.

[Luke 42078]

Thanks for the feedback !

[mastrmind11 722]

17 hours ago, nuentes said:

I believe I just resolved this. I had not set a squash rule in the NFS shares, so they were using the default setting of "no_all_squash". I added the following:

all_squash,anonuid=1000,anongid=1000

This being because andre:andre are both uid and gid 1000 on the emby server. It appears that permissions on NFS don't work quite the way I had imagined. Anyway, after adding this, it appears that Emby is again able to save and modify nfo files.

that was going to be my next request, are the mounts shared via nfs, show your fstab :).   NFS uid/gid has to match on both client and server (and group members have to match on both client and server).  all_squash will give anyone anon access.  nice work.