Open xinstein opened 1 year ago
Hi, this is possibly a bug of the music app. Please also report it here: https://github.com/owncloud/music/issues
The Music app doesn't do anything too exotic in this case. In essence, it calls IRootFolder::getUserFolder($userId)
to get the home folder of the targeted user and then calls Folder::get($path)
on that home folder object to get the folder which has been configured as the music library root for that user. This happens in a context where there is no logged-in user.
Open the music library folder (which is an external storage) in Files app in the web browser
Hi, are you using the session credentials to authenticate the external storage?
It's a local mount
Open the music library folder (which is an external storage) in Files app in the web browser
Hi, are you using the session credentials to authenticate the external storage?
It's a local mount, I don't think it needs a credential.
The mount is a vhgfs from a windows directory.
Heres my full setup:
Windows 10 host, ubuntu 20.04 guest in virtualbox, nextcloud is installed via docker-compose in ubuntu. The music folder is a windows directory of an ntfs drive, mounted in ubuntu using virtualbox's vhgfs, bind-mounted in nextcloud's docker-compose configuration.
I've been using this setup since more than two years ago, and music app is among my most intensely used apps.
Forgot to mention that the Music web app works without any problem.
I just confirmed that this problem still persists in nxtcloud 25.0.2.3
This problem might not be specific to the music app.
I get 'file not found' notices from time to time when using the files app, but this is much harder to reproduce. Currently all observed occurrences are in folders of external storage, but that's not a sure thing.
I feel it necessary to also report this bug to files_external app
What's the status of this issue ? What more info should I provide ?
I do not have the music app installed, and after upgrading to Nextcloud 26.0 I get this warning:
Clicking the "List of invalid files..." link gives me this:
Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.
Results
=======
- core
- INVALID_HASH
- core/js/mimetypelist.js
Raw output
==========
Array
(
[core] => Array
(
[INVALID_HASH] => Array
(
[core/js/mimetypelist.js] => Array
(
[expected] => 4b0a99fbab7bc4824176101150bd0ab2b553e128a390e0f872580db4541462b31aad13099fd41533b6695d1b185dabca26a45e9a78227cfb9479eafa439c7bff
[current] => a8e818876a7eff2a2137601eafc6c7d96b99cbf27d94ff9bb59eb237bdab92076ecc2828242bb37551c9c8b6772c0718887bd49cee5b49b3be48d3b9ecaa558f
)
)
)
)
Possibly related?
@wwklnd Even though you have the same integrity check failure as the OP, I don't believe that this has anything to do with the actual problem reported here, neither in your nor in the OP's case. It just means that for both of you, this one file core/js/mimetypelist.js
has been modified by someone after the Nextcloud installation.
@paulijar Gotcha!
I managed to narrow this issue down to a couple of methods.
To begin with, here's a simplified call stack for the music app when a music stream is requested via a client:
1. OCA\Music\Controller\SubsonicController->stream("track-5815")
2. OCA\Music\Controller\SubsonicController->download("track-5815")
3. OCA\Music\Controller\SubsonicController->getFilesystemNode(50253)
4. OCA\Music\Utility\LibrarySettings->getFolder("<username>")
5. OCA\Music\Utility\Util::getFolderFromRelativePath(["OC\\Files\\Node\\LazyUserFolder"], "/My Music/")
6. OC\Files\Node\LazyUserFolder->get("/My Music/")
7. OC\Files\Node\Root->get("/<username>/files/My Music")
The last method (Root::get() : Node
) makes a call to View::getFileInfo() : FileInfo
which itself queries Filesystem::getMountManager()->find() : Mount
to retrieve the matching Mount
and Storage
objects for a given path.
View::getFileInfo() : FileInfo
then calls the View::getCacheEntry() : ICacheEntry
method (passing the Storage
object and file path as parameters) which tries to retrieve data (file metadata?) from a cache or tries to load it directly from storage if there is a cache miss.
Now, here's the interesting part: In case of a cache miss, the Storage
object is used to check if the file even still exists (using Storage::file_exists() : boolean
). This should return true
assuming that Filesystem::getMountManager()->find() : Mount
returns the correct Mount
and Storage
objects.
I've observed that for the root path of local external storages (in my case "/My Music"), the home::<username>
Storage
object is returned (the home storage for a particular user is located at /var/www/html/data/<username>/files
).
This is causing the file_exists()
check to fail because there is no such folder in my home storage - it's the name of my share.
Here's my current workaround (which will only work if your "Music" folder is a child of the root user folder):
I've added a call to Folder::getDirectoryListing()
in the LibrarySettings::getFolder()
method.
public function getFolder(string $userId) : Folder {
$userHome = $this->rootFolder->getUserFolder($userId);
$path = $this->getPath($userId);
$userHome->getDirectoryListing();
return Util::getFolderFromRelativePath($userHome, $path);
}
Hi, please update to 25.0.7 or better 26.0.2 and report back if it fixes the issue. Thank you!
My goal is to add a label like e.g. 26-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!
If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+
Just performed an upgrade to NC 26.0.2. Unfortunately the issue was not fixed and the proposed workaround is still valid.
Here's my current workaround (which will only work if your "Music" folder is a child of the root user folder): I've added a call to
Folder::getDirectoryListing()
in theLibrarySettings::getFolder()
method.public function getFolder(string $userId) : Folder { $userHome = $this->rootFolder->getUserFolder($userId); $path = $this->getPath($userId); $userHome->getDirectoryListing(); return Util::getFolderFromRelativePath($userHome, $path); }
This sounds like a fix in the music app then. Cc @paulijar
Oh, I don't think that's a good idea. This issue affects other apps (e.g. files, notes) as well, but it may not be as noticeable. Please see my previous comment on this thread:
In case of a cache miss, the
Storage
object is used to check if the file even still exists (usingStorage::file_exists() : boolean
). This should returntrue
assuming thatFilesystem::getMountManager()->find() : Mount
returns the correctMount
andStorage
objects.I've observed that for the root path of local external storages (in my case "/My Music"), the
home::<username>
Storage
object is returned (the home storage for a particular user is located at/var/www/html/data/<username>/files
).This is causing the
file_exists()
check to fail because there is no such folder in my home storage - it's the name of my share.
Cc @icewind then 🤷♂️
Maybe I'm missing something here, but I think you were trying to mention @icewind1991? :sweat_smile:
This may not be a caching issue.
I've observed that after some time (30 seconds to a few minutes) almost every external mount point is removed from the oc_mounts
table. It appears that when the getDirectoryListing()
method is invoked on the user's root folder, all external mount points are subsequently reinserted into the table.
I've also noticed that one mount point entry (see screenshots) is duplicated several times for the same user but with different root_id
s.
Before reloading the root directory | After reloading the root directory |
---|---|
Possibly related to #40353.
This issue is still present on Nextcloud server v28.0.0
This issue is not present on 24.0.5.1, and present on 24.0.8.2. Is that not specific enough to find a cause?
The issue seems to be gone, I recently updated from
'version' => '27.1.5.1',
to
'version' => '27.1.7.2',
Thought I should report here.
So what's the status of this issue on 28.x.x
⚠️ This issue respects the following points: ⚠️
Bug description
/MyMusicLibrary
is an external storage (files_external) of local directoryThis happens most of the time, except when the directory
/MyMusicLibrary
has just been accessed in the Files app.This problem is not present in
24.0.5.1
, I recently upgraded to24.0.8.2
and this is when the problem starts to happen. I now upgraded to25.0.2.3
and the problem still persists.Steps to reproduce
This problem specifically affects ONLY subsonic clients, the music webapp works seamlessly as usual.
Expected behavior
It should work as in previous versions.
Installation method
Community Docker image
Operating system
Debian/Ubuntu
PHP engine version
None
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 22.2.3 to 22.2.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
What's this? I've never noticed this problem.
I've done an
./occ maintenance:mimetype:update-js
, Has this anything to do with this integrity failure?Nextcloud Logs
No response
Additional info
No response