Thanks for taking the time to reply to a user here. I remember a report as early as mid-2015 regarding this issue but unfortunately it got buried and we weren’t sure where to follow up. I’d like to get this solved.
On OSMC, disks are automatically mounted under the /media directory. The subdirectory is the label (if existing) of each partition.
I would recommend the following patch:
From fa0cc3eb2b0cd4ccd7dea3983c0b5357c19e4509 Mon Sep 17 00:00:00 2001
From: Sam Nazarko <email@samnazarko.co.uk>
Date: Fri, 2 Feb 2018 00:48:23 +0000
Subject: [PATCH] Fix error 401 with Yatse when accessing auto-mounted hard
disks. This effectively enforces allowsharing. Disks that want more finely
grained permissions should be mounted via fstab outside of /media.
Signed-off-by: Sam Nazarko <email@samnazarko.co.uk>
---
xbmc/utils/FileUtils.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xbmc/utils/FileUtils.cpp b/xbmc/utils/FileUtils.cpp
index 818fc8a..a682eb7 100644
--- a/xbmc/utils/FileUtils.cpp
+++ b/xbmc/utils/FileUtils.cpp
@@ -146,6 +146,8 @@ bool CFileUtils::RemoteAccessAllowed(const std::string &strPath)
return true;
else if (StringUtils::StartsWithNoCase(realPath, "plugin://"))
return true;
+ else if (StringUtils::StartsWithNoCase(realPath, "/media/")) /* OSMC mounted disks */
+ return true;
else
{
std::string strPlaylistsPath = CSettings::GetInstance().GetString(CSettings::SETTING_SYSTEM_PLAYLISTSPATH);
--
2.7.4
Unfortunately I don’t have Yatse to test this, but would appreciate if the proposed solution could be tried so we can get something included in OSMC for the next update.
I’m happy to make testing available if you let me know which devices you’d like to try this on.
You can also try with embedded Chorus web interface or anything that can access the files.
Your patch would work but :
It can’t be disabled by the users easily, asking them to mount drives to another mount point if they do not want to share something is complex.
It does not fix another issue that is that since it’s not seen as a proper source it’s not available for remotes to browse via JSON. (Files.GetDirectory). This is the second major issue with Kodi linux distributions that auto mount drives.
Users can then just change the allowSharing or remove the file if they do not want those features.
But issue number 2 is recurrent and as frequent as the streaming issue.
A proper fix on Kodi side would be to finally allow setting the allowSharing from GUI + proper handling of auto mounted drives as sources for Files.GetDirectory, but well i can no more contribute to Kodi and not a lot of people cares about JSON and is a lot more work to do properly.
If we patch the system directory and add a pre-defined sources.xml there, then this can take effect from the very next update. However, it is not very configurable; as any changes made would be reverted whenever Kodi is updated. This makes it difficult to make allowsharing changes to be persistent. If there’s no GUI option for this; perhaps it should be kept for all mounted disks.
We do recommend those that want to mount disks with more control / in a more permanent fashion use fstab.
Alternatively, we can define it in a sources.xml file under the local user’s userdata. However, for obvious reasons, we can only do this for new installations.
@fzinken also suggested that we could disable Set Content from being ran on auto-mounted disks; forcing the user to create a source manually. I’m not sure how some users would react to this change however.
Providing an source.xml for new users should cover most needs.
Most users do read FAQ or contact support on issues so all actual users are more or less aware of the issue and fix.
The thing with automounted by default in /media and having /media by default accessible without easy ways for users to revert except doing things at OS level sounds not that cool from user security point of view.
Source.xml pre configured can be removed from Kodi GUI.
Anyway I deal with support for that issue since May 2013, and I was lucky to be able to have a consensus on a solution as else no access at all would have been possible. So anything you do would be cool for me But user’s security always matters before support.
Okay. I’ll add a sources.xml and add it to the system directory.
I’ll patch CApplication so that it copies the sources file over when Kodi starts if one does not yet exist. This will also cover the issue of people moving the ~/.kodi directory.
But user’s security always matters before support.