[Bug]: Unable to access "ALBAUM" in Nextcloud 29.0.x
nikitakothari06 opened this issue · 12 comments
⚠️ This issue respects the following points: ⚠️
- This is a bug, not a question or a configuration/webserver/proxy issue.
- This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- I agree to follow Nextcloud's Code of Conduct.
Bug description
I have installed Nextcloud 29.0.1 on my test server with PHP 8.0 & Mysql 8.0 When I first create the albaum from "Photos --> +Add --> Add new albaum" the albaum gets created. However When I upload any image in it, it throws the following error.
Failed to add xxxx.jpg to collection /photos/[[username]]/albums/[[albaum]]
And after that when I visit "Albaum" section from left side menu it throws the "An error occurred" error.
I am attaching the nextcloud.log file for the reference.
Steps to reproduce
- Login to the admin panel.
- Visit the "Photos" section from right top section.
- Create the new albaum.
- Upload a new file in the created albaum. and it will throw the Failed to add xxxx.jpg to collection /photos/[[username]]/albums/[[albaum]] error.
- Try to visit "Albaum" section again and it will throw "An error occurred" error.
Expected behavior
The new albaum should created without any error and in that albaum, user should be able to upload the files.
Installation method
Community Manual installation with Archive
Nextcloud Server version
29
Operating system
RHEL/CentOS
PHP engine version
PHP 8.0
Web server
Apache (supported)
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
OC\Files\Type\Loader::getMimetypeById(): Argument nextcloud/server#1 ($id) must be of type int, string given, called in [[root_path]]/[[sub_dir]]/apps/photos/lib/Album/AlbumMapper.php on line 207
photos/lib/Album/AlbumMapper.php
Line 211 in ca18d17
The call $this->mimeTypeLoader->getMimetypeById($mimeId) expects an integer but received a string. The value is coming from the database, and thus I fail to understand why it ended up as string.
You can patch the photos app like below to have the data logged and the file with the broken mimetype ignored:
Index: lib/Album/AlbumMapper.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/lib/Album/AlbumMapper.php b/lib/Album/AlbumMapper.php
--- a/lib/Album/AlbumMapper.php (revision ca18d179837d6956f0e860fb556991faf07d5eff)
+++ b/lib/Album/AlbumMapper.php (date 1717175935513)
@@ -18,6 +18,8 @@
use OCP\IL10N;
use OCP\IUserManager;
use OCP\Security\ISecureRandom;
+use OCP\Server;
+use Psr\Log\LoggerInterface;
class AlbumMapper {
private IDBConnection $connection;
@@ -208,6 +210,10 @@
$albumId = (int)$row['album_id'];
if ($row['fileid']) {
$mimeId = $row['mimetype'];
+ if (is_int($mimeId) === false) {
+ Server::get(LoggerInterface::class)->warning('Ignoring file because the mimetype is not an integer', ['row' => $row]);
+ continue;
+ }
$mimeType = $this->mimeTypeLoader->getMimetypeById($mimeId);
$files[] = new AlbumFile((int)$row['fileid'], $row['file_name'], $mimeType, (int)$row['size'], (int)$row['mtime'], $row['etag'], (int)$row['added'], $row['owner']);
}
(the patch path is relative to the photos app, not the server directory)
Applied the patch on my server and now I am able to upload the files and create an albaum.
However when I come out of the albaum, it shows 0 photos 0 videos (despite of adding multiple pictures) and after working on some other module, when I come back to the my albaum, it shows "This albaum does not have photos or videos yet"
Check the logfile for "Ignoring file because the mimetype is not an integer" and post the complete line.
This one of the many lines.
{"reqId":"Zl2_LQHywNHop2lTXwceYgAAAAk","level":2,"time":"2024-06-03T13:03:41+00:00","remoteAddr":"[[ip_addr]]","user":"[[username]]","app":"no app in context","method":"PROPFIND","url":"[[subdir_path]]/remote.php/dav/photos/[[username]]/albums/test_albaum/","message":"Ignoring file because the mimetype is not an integer","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0","version":"29.0.1.1","data":{"row":"{"fileid":"401","mimetype":"10","album_id":"15","size":"9560","mtime":"1717418783","etag":"7f9677a7a6cb2c1502fc9f630d67565c","added":"1717419088","owner":"[[username]]","file_name":"images4.jpg","album_name":"test_albaum"}"}}
Strange, I fail to understand why the mimetype is not an integer on your end.
This modified version of the patch should also log the type.
Would you mind to apply it and share a log message again?
Index: lib/Album/AlbumMapper.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/lib/Album/AlbumMapper.php b/lib/Album/AlbumMapper.php
--- a/lib/Album/AlbumMapper.php (revision ca18d179837d6956f0e860fb556991faf07d5eff)
+++ b/lib/Album/AlbumMapper.php (date 1717429102912)
@@ -18,6 +18,8 @@
use OCP\IL10N;
use OCP\IUserManager;
use OCP\Security\ISecureRandom;
+use OCP\Server;
+use Psr\Log\LoggerInterface;
class AlbumMapper {
private IDBConnection $connection;
@@ -208,6 +210,10 @@
$albumId = (int)$row['album_id'];
if ($row['fileid']) {
$mimeId = $row['mimetype'];
+ if (is_int($mimeId) === false) {
+ Server::get(LoggerInterface::class)->warning('Ignoring file because the mimetype is not an integer', ['row' => $row, 'type_mimetype' => gettype($mimeId)]);
+ continue;
+ }
$mimeType = $this->mimeTypeLoader->getMimetypeById($mimeId);
$files[] = new AlbumFile((int)$row['fileid'], $row['file_name'], $mimeType, (int)$row['size'], (int)$row['mtime'], $row['etag'], (int)$row['added'], $row['owner']);
}
The values are always strings when they come from the DB.
IMimeTypeLoader got stricter regarding types recently: nextcloud/server#36252 hence the new error.
@nikitakothari06, could you create a PR with the patch @kesselb provided?
I guess you can fix it on your installation by changing
$mimeId = $row['mimetype'];to
$mimeId = (int)$row['mimetype'];in
lib/Album/AlbumMapper.php
I tried this and it worked for the issue I reported. However that is still not complete. When I click on the newly created albaum and try to upload new picture, the script does not allow me to do so. (refer screenshot)
I can add the photos from the existing one with "Add to album" button but "+New" button is not working.
The values are always strings when they come from the DB.
I thought so too.
Surprisingly some values have the right type already.
Maybe something changed in doctrine or pdo making that work.
I tried this and it worked for the issue I reported. However that is still not complete. When I click on the newly created albaum and try to upload new picture, the script does not allow me to do so. (refer screenshot)
Please log a new issue for it at https://github.com/nextcloud/photos/issues
Also the button works fine over here ;)
There is a setting for that in PDO: ATTR_STRINGIFY_FETCHES
I recall something changed about this, but I couldn't find what…
Is there any ETA for the next version with these changes ?
Please log a new issue for it at
Also I created an separate issue for this. #2496
Is there any ETA for the next version with these changes ?
Should be in the next releases: https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule