Jump to content

Network library permissions


fc7
Go to solution Solved by fc7,

Recommended Posts

I'm not sure if I found a bug, or is just by design.

 

I'm running Mediabrowser server 3.0.5518.4 on CentOS 7 and my media library is hosted on a Windows SMB fileshare that MB access through the network. This share has read-only permissions.

I mounted this SMB share on my CentOS server so it looks local to any application that runs on this machine. Then I configured MB library to point to this local folder. The library was successfully scanned, all the metadata was retrieved correctly from the internet and I was able to watch content from a web browser and also from my iPad. So far so good.

 

All my movies and tv shows have subtitles, they were scanned and detected correctly by MB. The problem is that when I try to enable the subs for any movie or tv show, they don't work. On any device (web or tablet). Video and audio is ok but the subs just don't work.

I went through MB logs and I found that every time I enabled subs this error is logged (partial extract below, full trace attached):

 

Access to the path "/storage/Movies/WhatEverMovie/WhatEverMovie.spa.srt" is denied.

 

This is not true, since subs and video files are in the same folder on the share. I also try to open the subs file from the MB machine with vi, cat, more, etc. and there is no problem at all. I can read the file perfectly. Of course since the share is read-only I can only read the file, not modify it, delete it, etc.

 

I tried to change the permissions on the share to allow write access, just for the sake of testing and voila, subs started to work from MB.

 

Now my questions are, why MB will fail to display the subtitles if it doesn't have write access to the file? Is this a bug? By design?

 

Any other application/media player I tried had no problem at all to display the video and the subs from this read-only network share.

 

Thanks in advance for your replies.

 

Cheers.

Full_trace.txt

Link to comment
Share on other sites

thefirstofthe300

What is the output of ls -l /storage/Movies/WhatEverMovie? It could be that the subtitle itself has permissions that won't allow MBS to read them.

 

Woops. Didn't catch the part that said it started working.

 

That is interesting that it won't work without having write access.

 

@@jose Being the RPM maintainer, what user does MBS run as? It would be nice to have confirmation so that I can help troubleshoot the RPM based distros too.

Edited by DaBungalow
Link to comment
Share on other sites

What is the output of ls -l /storage/Movies/WhatEverMovie? It could be that the subtitle itself has permissions that won't allow MBS to read them.

 

@@jose Being the RPM maintainer, what user does MBS run as? It would be nice to have confirmation so that I can help troubleshoot the RPM based distros too.

 

Here you are:

total 4581824
-rwxr-xr-x 0 MediaBrowserServer media 4691575681 Jan 15 14:42 WhatEverMovie.mkv
-rwxr-xr-x 0 MediaBrowserServer media      75640 Sep 13  2012 WhatEverMovie.spa.srt

As you can see MB has read access to both files (movie and srt). I can also access the subtitle file with different tools like "vi", "cat", "more", etc. successfully.

 

I didn't check the code obviously but is it possible that when you generate the file handle to access the subtitles file you are using a read-write mode instead of just read? Because that can generate this kind of problem on a read-only file.

 

One last note. Even when you can see that MediaBrowserServer have write access to the file, this is not really true since the network share is read-only. This is only how cifs-utils mounts and presents the permissions to the OS. The fileserver is a Windows Server machine.

 

Thanks.

Link to comment
Share on other sites

thefirstofthe300

Here you are:

total 4581824
-rwxr-xr-x 0 MediaBrowserServer media 4691575681 Jan 15 14:42 WhatEverMovie.mkv
-rwxr-xr-x 0 MediaBrowserServer media      75640 Sep 13  2012 WhatEverMovie.spa.srt

As you can see MB has read access to both files (movie and srt). I can also access the subtitle file with different tools like "vi", "cat", "more", etc. successfully.

 

I didn't check the code obviously but is it possible that when you generate the file handle to access the subtitles file you are using a read-write mode instead of just read? Because that can generate this kind of problem on a read-only file.

 

One last note. Even when you can see that MediaBrowserServer have write access to the file, this is not really true since the network share is read-only. This is only how cifs-utils mounts and presents the permissions to the OS. The fileserver is a Windows Server machine.

 

Thanks.

 

Yeah. This is definitely a weird error. I will poke around the code base and see if it isn't opening in read+write mode.

Edited by DaBungalow
Link to comment
Share on other sites

Yeah. This is definitely a weird error. I will poke around the code base and see if it isn't opening in read+write mode.

Cool. I'll be looking forward your findings.

 

In case you are interested I took a SMB protocol network capture between the MB server and the fileserver while trying to enable subs.

I can see MB asking the fileserver for the srt and video files properties (one of which indicates that the files are read-only). Then the access denied error is logged in MB logfile and there is no attempt to actually open the srt file for reading or writing. Just a read request for the video file that is succesfully answered by the file server starting to serve the video file.

 

Let me know if you want me to upload the network trace.

Link to comment
Share on other sites

Every file the server creates gets aasigned the user mediabrowserserver and the group media with read write for both. the server run as MediaBrowserServer which is part of the group media

Link to comment
Share on other sites

  • Solution

Yeah. This is definitely a weird error. I will poke around the code base and see if it isn't opening in read+write mode.

 

Ok, so I had some time to poke around the code this morning and I think I found the problem.

 

I have only checked this file:

 
As far as I can see you are opening the subtitles file in lines 165, 776 and 805.
In line 165 you are opening the file and also specifying a FileAccess parameter for the FileStream constructor, correctly using FileAccess.Read which will open the file for reading only (no write access).
 
The problem is that in line 776 and 805 you are ommiting the FileAccess parameter in which case .NET defaults to ReadWrite access. So if the subtitles file is read-only or MediaBrowser server has read permissions only for this file, opening the file for read-write will fail and throw the exception.
 
From MSDN:
 
"For constructors without a FileAccess parameter, if the mode parameter is set to Append, Write is the default access. Otherwise, the access is set to ReadWrite"
 
To fix the problem FileAccess.Read should be added to the FileStream constructor in lines 776 and 805.
 

776: should change from

 

using (var file = new FileStream(path, FileMode.Open))

 

to:

 

using (var file = new FileStream(path, FileMode.Open, FileAccess.Read))

 

805: should change from

 

using (var file = new FileStream(srcFile, FileMode.Open))

 

to:

 

using (var file = new FileStream(srcFile, FileMode.Open, FileAccess.Read))

 

This might not be the complete solution since you may need to go through other parts of the code and fix it accordingly but it's a good start.

Edited by fc7
  • Like 1
Link to comment
Share on other sites

Should I fill this information through any bug tracking system to keep track of it?

Is there any bug tracking system already in place?

 

I don't mind filling the bug and I'm really looking forward a fix, since I can't use subs until then, from any device.

 

BTW I poke around the code a little bit more but it seems that the problematic lines are the ones I already reported, so that's good.

Edited by fc7
Link to comment
Share on other sites

it's resolved for the next release, thanks.

 

Sweet! Thank you Luke.

Link to comment
Share on other sites

  • 3 weeks later...

Just wanted to thank you guys. I updated this morning to the latest beta version and this problem is now fixed.

 

Keep up with the great work!

 

BTW I'm now a supporter and Emby evangelist :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...