Bug description
After upgrading my Nextcloud installation to Nextcloud 34.0.3, I am experiencing two image preview problems:
- Some normal JPEG photos generate a preview that is essentially a blurred/gradient image with no recognizable content, even though the original JPEG is perfectly valid and can be decoded and resized correctly outside Nextcloud.
- HEIC photos can no longer generate previews at all. Both the thumbnail/preview and the large image view are affected.
The problems appear to be related to the Nextcloud preview generation system rather than Apache, Cloudflare, file permissions, ImageMagick, or the original image files.
The server was working normally before the upgrade.
Environment
- Nextcloud Server: 34.0.3
- Preview Generator app: 5.14.0
- Photos app: 7.0.0
- OS: Debian
- Architecture: ARM64 / Raspberry Pi 5
- Hardware: Raspberry Pi 5, 8 GB RAM
- Web server: Apache 2.4.68
- PHP: 8.5.8
- Database: MariaDB
- ImageMagick: installed and working
- PHP extensions:
- Redis: enabled for local/locking memcache
- Storage: local storage through a MergerFS pool
- Cloudflare: used as the public reverse proxy/CDN
- Direct LAN access to Apache was also tested, so Cloudflare is not required to reproduce the problem.
Relevant Nextcloud configuration:
overwrite.cli.url = https://nextcloud.circuitwater.com
overwritehost = nextcloud.circuitwater.com
overwriteprotocol = https
enable_previews = true
preview_ffmpeg_path = /usr/bin/ffmpeg
enabledPreviewProviders:
OC\Preview\Movie
OC\Preview\MP4
OC\Preview\MKV
OC\Preview\AVI
OC\Preview\Image
OC\Preview\HEIC
PHP CLI memory limit:
memory_limit=-1
Problem 1: JPEG preview becomes an unusable gradient/blurred image
I have two JPEG files from the same photo collection.
They are different photos: one was taken with the front camera and one with the rear camera.
The important point is that one works correctly and the other does not, despite both being valid JPEG files.
Working JPEG
Filename:
26-08-21 07-52-38 9007.jpg
Nextcloud file ID:
879145
Original size:
8,891,981 bytes
Original dimensions:
3024 x 4032
Broken JPEG
Filename:
26-08-21 07-59-21 9008.jpg
Nextcloud file ID:
879144
Original size:
3,763,725 bytes
Original dimensions:
3088 x 2316
The broken image is not simply low quality.
The generated preview is essentially a smooth gradient / blurred image where the actual contents of the photograph cannot be recognized.
The original file itself is valid.
Database information
For the broken file:
SELECT fileid, path, mimetype, size, mtime
FROM oc_filecache
WHERE fileid = 879144;
Relevant result:
fileid: 879144
path: files/Photos/2026/08/26-08-21 07-59-21 9008.jpg
mimetype: 8
size: 3763725
For comparison, the working file is:
fileid: 879145
path: files/Photos/2026/08/26/26-08-21 07-52-38 9007.jpg
mimetype: 8
size: 8891981
Preview database entries
Initially, the broken JPEG had multiple preview entries:
file_id width height size max
879144 48 64 1534 0
879144 64 64 1731 0
879144 192 256 9184 0
879144 256 256 11001 0
879144 256 341 14777 0
879144 768 1024 102863 0
879144 1024 1365 175400 0
879144 2316 3088 849744 1
The preview files existed physically under:
/mnt/pool/nextcloud_data/appdata_ocfy6fwmnciv/preview/9/6/c/2/8/f/9/879144/
For example:
2316-3088-max.jpg
1024-1365.jpg
768-1024.jpg
256-341.jpg
256-256-crop.jpg
48-64.jpg
64-64-crop.jpg
The corresponding working file 879145 also had the expected preview hierarchy.
Preview regeneration test
I deleted the preview directory for file ID 879144:
sudo rm -rf
/mnt/pool/nextcloud_data/appdata_ocfy6fwmnciv/preview/9/6/c/2/8/f/9/879144
I then deleted the corresponding database records:
DELETE FROM oc_previews
WHERE file_id = 879144;
Verified:
preview_count = 0
Then ran:
sudo -u www-data php /var/www/nextcloud/occ preview:generate 879144
Result:
preview generated
However, immediately after this operation, only two preview files were generated:
2316-3088-max.jpg
48-64.jpg
Later, other previews appeared when they were requested/generated:
256-256-crop.jpg
768-1024.jpg
256-341.jpg
The problem still remained.
Important test: Nextcloud API does return HTTP 200
The Photos preview API was tested directly.
Request:
GET /index.php/apps/photos/api/v1/preview/879144?etag=c808473c0228963909100f77b11886fc&x=256&y=256
Response:
HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Disposition: inline; filename="192-256.jpg"
ETag: "c808473c0228963909100f77b11886fc"
So the request is not failing at HTTP level.
The browser receives a JPEG response, but the rendered image is visually incorrect / effectively a gradient.
The same issue can be observed through direct LAN access:
http://192.168.0.102/
Therefore this does not appear to be a Cloudflare-only problem.
Important test: original JPEG is completely valid
The original file:
/mnt/pool/nextcloud_data/admin/files/Photos/2026/08/26-08-21 07-59-21 9008.jpg
was tested directly using ImageMagick:
sudo identify
'/mnt/pool/nextcloud_data/admin/files/Photos/2026/08/26/26-08-21 07-59-21 9008.jpg'
Result:
JPEG 3088x2316
8-bit sRGB
3.58937MiB
Detailed information:
Format: JPEG
Geometry: 3088x2316+0+0
Colorspace: sRGB
Compression: JPEG
Quality: 100
Orientation: RightTop
ImageMagick can therefore decode the original JPEG correctly.
Important test: ImageMagick can resize the original correctly
I manually resized the original JPEG:
sudo convert
'/mnt/pool/nextcloud_data/admin/files/Photos/2026/08/26-08-21 07-59-21 9008.jpg'
-auto-orient
-resize '256x256>'
/tmp/9008-im.jpg
Result:
JPEG 192x256
The generated file is a normal, recognizable JPEG.
I also tested PHP GD directly:
$src = imagecreatefromjpeg($f);
Result:
GD DECODE OK: 3088x2316
and resizing with GD also worked:
GD RESIZE OK
So both ImageMagick and GD can correctly decode and resize the original JPEG.
This strongly suggests that the problem is somewhere in the Nextcloud preview generation/request path rather than the JPEG itself.
Preview Generator configuration
The Preview Generator app is:
previewgenerator 5.14.0
Configuration:
squareSizes = 32 256
squareUncroppedSizes = 256 384 512
widthSizes = 256 384 512
heightSizes = 256 384
Full configuration:
{
"apps": {
"previewgenerator": {
"enabled": "yes",
"heightSizes": "256 384",
"installed_version": "5.14.0",
"sizes": "{"square":[32,256],"width":[256,384,512],"height":[256,384]}",
"squareSizes": "32 256",
"types": "filesystem",
"widthSizes": "256 384 512"
}
}
}
Problem 2: HEIC preview generation completely fails
A second and more serious regression affects HEIC files.
Example:
Filename:
IMG_5590.HEIC
Nextcloud file ID:
295274
Nextcloud path:
files/Photos/2021/11/IMG_5590.HEIC
File size:
675576 bytes
Database:
SELECT fileid, path, mimetype, size, mtime
FROM oc_filecache
WHERE path LIKE '%IMG_5590.HEIC';
Result:
fileid: 295274
path: files/Photos/2021/11/IMG_5590.HEIC
mimetype: 31
size: 675576
The actual file exists:
/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC
ImageMagick can read the HEIC file
I tested it as root:
sudo identify
'/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC'
Result:
JPEG 4032x3024
4032x3024+0+0
8-bit sRGB
675576B
I also tested it as www-data:
sudo -u www-data identify
'/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC'
Same result:
JPEG 4032x3024
4032x3024+0+0
8-bit sRGB
675576B
So permissions and ImageMagick access are not the problem.
PHP Imagick can read the HEIC file
I tested PHP Imagick directly:
$f="/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC";
$im = new Imagick();
$im->readImage($f);
echo "format=" . $im->getImageFormat() . "\n";
echo "size=" . $im->getImageWidth() . "x" . $im->getImageHeight() . "\n";
Result:
IMAGICK HEIC READ OK
format=JPEG
size=4032x3024
I also tested:
Imagick::queryFormats("HEI*")
Result:
Array
(
[0] => HEIC
)
Therefore PHP Imagick explicitly reports HEIC support.
HEIC provider is explicitly enabled in Nextcloud
Nextcloud configuration contains:
enabledPreviewProviders:
OC\Preview\Movie
OC\Preview\MP4
OC\Preview\MKV
OC\Preview\AVI
OC\Preview\Image
OC\Preview\HEIC
And:
enable_previews = true
However:
sudo -u www-data php /var/www/nextcloud/occ preview:generate 295274
fails with:
In Generator.php line 413:
No provider successfully handled the preview generation
This is different from simply having no HEIC support at the OS level.
The provider is enabled, ImageMagick supports HEIC, PHP Imagick can read the file, and the file is valid.
Nevertheless, Nextcloud's preview generator does not successfully handle the file.
Expected behavior
For a valid JPEG:
occ preview:generate
should generate a correct preview that visually matches the original image.
For a valid HEIC file:
occ preview:generate
should generate a JPEG preview.
The Photos application should then display:
- correct thumbnails
- correct preview images
- correct large image views
Actual behavior
JPEG
The original JPEG is valid and can be decoded and resized correctly by both ImageMagick and PHP GD.
Nextcloud returns HTTP 200 and a JPEG from the Photos preview API, but the displayed image can be an essentially featureless gradient/blur rather than the actual photograph.
HEIC
Nextcloud fails to generate the preview:
No provider successfully handled the preview generation
As a result, HEIC thumbnails/previews and large image display are broken.
Additional observations
The public hostname configuration has also been tested.
Local request:
http://192.168.0.102/
works.
Public request:
https://nextcloud.circuitwater.com/
also works and returns the normal Nextcloud login redirect.
The public URL correctly uses HTTPS:
overwrite.cli.url = https://nextcloud.circuitwater.com
A test through the public hostname showed:
HTTP_HOST=nextcloud.circuitwater.com
HTTPS=
SERVER_PORT=80
REQUEST_SCHEME=http
REMOTE_ADDR=127.0.0.1
while the Nextcloud configuration test correctly showed:
overwrite.cli.url='https://nextcloud.circuitwater.com'
overwritehost='nextcloud.circuitwater.com'
overwriteprotocol='https'
Therefore I do not believe the preview problem is caused by the public URL/reverse proxy configuration.
Direct LAN requests reproduce the relevant behavior as well.
Possible relation to Nextcloud 34
This appears to be a regression in the Nextcloud 34 preview subsystem.
There is already a closely related upstream issue:
Nextcloud Server #62546 — "Cannot generate previews for heic files since upgrade to 34.0.2"
That report describes HEIC preview generation failing after upgrading to Nextcloud 34.0.2, on Debian/Ubuntu with PHP 8.5, Apache and ImageMagick. GitHub
There is also Nextcloud Server #62802 — "Imagemagick preview providers are disabled", which reports preview generation problems in Nextcloud 34 involving ImageMagick-based providers. GitHub
My environment and symptoms appear closely related, but I am also seeing the additional JPEG preview corruption described above.
What I have already ruled out
I have tested the following:
- Original JPEG is valid.
- Original HEIC file exists.
- ImageMagick can decode the JPEG.
- ImageMagick can decode the HEIC.
- PHP GD can decode and resize the JPEG.
- PHP Imagick can read the HEIC.
- Imagick::queryFormats("HEI*") reports HEIC.
- www-data can access both files.
- Preview directories are writable by www-data.
- Preview database records were manually removed and regenerated.
- occ preview:generate was tested directly.
- Cloudflare is not required to reproduce the issue.
- Direct LAN access to Apache was tested.
- enable_previews is enabled.
- OC\Preview\HEIC is explicitly enabled.
- PHP CLI memory limit is unlimited (-1).
Questions for the Nextcloud developers
Could you please confirm whether this is a known regression in Nextcloud 34.0.x?
In particular:
- Why does OC\Preview\HEIC fail to handle a HEIC file when PHP Imagick can successfully read it?
- Why does occ preview:generate 295274 return No provider successfully handled the preview generation instead of successfully using the HEIC provider?
- Could the JPEG gradient/blurred preview problem be related to the same preview provider changes in Nextcloud 34?
- Is there a recommended workaround or fixed version?
- If this is already covered by an existing issue, should this report be considered a duplicate?
I would prefer to avoid manually modifying the preview database or preview files because the issue affects normal Nextcloud preview generation and appears to be reproducible with valid image files.
Minimal reproduction
For the HEIC issue, the most direct reproduction on my system is:
sudo -u www-data php /var/www/nextcloud/occ preview:generate 295274
Expected:
preview generated
Actual:
No provider successfully handled the preview generation
Environment:
Nextcloud 34.0.3
PHP 8.5.8
Apache 2.4.68
Debian
MariaDB
Preview Generator 5.14.0
Imagick + GD + EXIF
HEIC support available in Imagick
Relevant commands/results
php -v
PHP 8.5.8 (cli)
php -m | grep -iE 'gd|imagick|exif'
exif
gd
imagick
sudo -u www-data php -m | grep -iE 'gd|imagick|exif'
exif
gd
imagick
sudo -u www-data php -r '
print_r(Imagick::queryFormats("HEI*"));
'
Array
(
[0] => HEIC
)
sudo -u www-data php /var/www/nextcloud/occ preview:generate 295274
No provider successfully handled the preview generation
Note: I am reporting this as a bug/regression rather than asking for configuration help, because the underlying image files can be decoded successfully by the same user (www-data) and the corresponding Nextcloud preview provider is explicitly enabled.
GitHub
Bug description
After upgrading my Nextcloud installation to Nextcloud 34.0.3, I am experiencing two image preview problems:
The problems appear to be related to the Nextcloud preview generation system rather than Apache, Cloudflare, file permissions, ImageMagick, or the original image files.
The server was working normally before the upgrade.
Environment
Relevant Nextcloud configuration:
overwrite.cli.url = https://nextcloud.circuitwater.com
overwritehost = nextcloud.circuitwater.com
overwriteprotocol = https
enable_previews = true
preview_ffmpeg_path = /usr/bin/ffmpeg
enabledPreviewProviders:
OC\Preview\Movie
OC\Preview\MP4
OC\Preview\MKV
OC\Preview\AVI
OC\Preview\Image
OC\Preview\HEIC
PHP CLI memory limit:
memory_limit=-1
Problem 1: JPEG preview becomes an unusable gradient/blurred image
I have two JPEG files from the same photo collection.
They are different photos: one was taken with the front camera and one with the rear camera.
The important point is that one works correctly and the other does not, despite both being valid JPEG files.
Working JPEG
Filename:
26-08-21 07-52-38 9007.jpg
Nextcloud file ID:
879145
Original size:
8,891,981 bytes
Original dimensions:
3024 x 4032
Broken JPEG
Filename:
26-08-21 07-59-21 9008.jpg
Nextcloud file ID:
879144
Original size:
3,763,725 bytes
Original dimensions:
3088 x 2316
The broken image is not simply low quality.
The generated preview is essentially a smooth gradient / blurred image where the actual contents of the photograph cannot be recognized.
The original file itself is valid.
Database information
For the broken file:
SELECT fileid, path, mimetype, size, mtime
FROM oc_filecache
WHERE fileid = 879144;
Relevant result:
fileid: 879144
path: files/Photos/2026/08/26-08-21 07-59-21 9008.jpg
mimetype: 8
size: 3763725
For comparison, the working file is:
fileid: 879145
path: files/Photos/2026/08/26/26-08-21 07-52-38 9007.jpg
mimetype: 8
size: 8891981
Preview database entries
Initially, the broken JPEG had multiple preview entries:
file_id width height size max
879144 48 64 1534 0
879144 64 64 1731 0
879144 192 256 9184 0
879144 256 256 11001 0
879144 256 341 14777 0
879144 768 1024 102863 0
879144 1024 1365 175400 0
879144 2316 3088 849744 1
The preview files existed physically under:
/mnt/pool/nextcloud_data/appdata_ocfy6fwmnciv/preview/9/6/c/2/8/f/9/879144/
For example:
2316-3088-max.jpg
1024-1365.jpg
768-1024.jpg
256-341.jpg
256-256-crop.jpg
48-64.jpg
64-64-crop.jpg
The corresponding working file 879145 also had the expected preview hierarchy.
Preview regeneration test
I deleted the preview directory for file ID 879144:
sudo rm -rf
/mnt/pool/nextcloud_data/appdata_ocfy6fwmnciv/preview/9/6/c/2/8/f/9/879144
I then deleted the corresponding database records:
DELETE FROM oc_previews
WHERE file_id = 879144;
Verified:
preview_count = 0
Then ran:
sudo -u www-data php /var/www/nextcloud/occ preview:generate 879144
Result:
preview generated
However, immediately after this operation, only two preview files were generated:
2316-3088-max.jpg
48-64.jpg
Later, other previews appeared when they were requested/generated:
256-256-crop.jpg
768-1024.jpg
256-341.jpg
The problem still remained.
Important test: Nextcloud API does return HTTP 200
The Photos preview API was tested directly.
Request:
GET /index.php/apps/photos/api/v1/preview/879144?etag=c808473c0228963909100f77b11886fc&x=256&y=256
Response:
HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Disposition: inline; filename="192-256.jpg"
ETag: "c808473c0228963909100f77b11886fc"
So the request is not failing at HTTP level.
The browser receives a JPEG response, but the rendered image is visually incorrect / effectively a gradient.
The same issue can be observed through direct LAN access:
http://192.168.0.102/
Therefore this does not appear to be a Cloudflare-only problem.
Important test: original JPEG is completely valid
The original file:
/mnt/pool/nextcloud_data/admin/files/Photos/2026/08/26-08-21 07-59-21 9008.jpg
was tested directly using ImageMagick:
sudo identify
'/mnt/pool/nextcloud_data/admin/files/Photos/2026/08/26/26-08-21 07-59-21 9008.jpg'
Result:
JPEG 3088x2316
8-bit sRGB
3.58937MiB
Detailed information:
Format: JPEG
Geometry: 3088x2316+0+0
Colorspace: sRGB
Compression: JPEG
Quality: 100
Orientation: RightTop
ImageMagick can therefore decode the original JPEG correctly.
Important test: ImageMagick can resize the original correctly
I manually resized the original JPEG:
sudo convert
'/mnt/pool/nextcloud_data/admin/files/Photos/2026/08/26-08-21 07-59-21 9008.jpg'
-auto-orient
-resize '256x256>'
/tmp/9008-im.jpg
Result:
JPEG 192x256
The generated file is a normal, recognizable JPEG.
I also tested PHP GD directly:
$src = imagecreatefromjpeg($f);
Result:
GD DECODE OK: 3088x2316
and resizing with GD also worked:
GD RESIZE OK
So both ImageMagick and GD can correctly decode and resize the original JPEG.
This strongly suggests that the problem is somewhere in the Nextcloud preview generation/request path rather than the JPEG itself.
Preview Generator configuration
The Preview Generator app is:
previewgenerator 5.14.0
Configuration:
squareSizes = 32 256
squareUncroppedSizes = 256 384 512
widthSizes = 256 384 512
heightSizes = 256 384
Full configuration:
{
"apps": {
"previewgenerator": {
"enabled": "yes",
"heightSizes": "256 384",
"installed_version": "5.14.0",
"sizes": "{"square":[32,256],"width":[256,384,512],"height":[256,384]}",
"squareSizes": "32 256",
"types": "filesystem",
"widthSizes": "256 384 512"
}
}
}
Problem 2: HEIC preview generation completely fails
A second and more serious regression affects HEIC files.
Example:
Filename:
IMG_5590.HEIC
Nextcloud file ID:
295274
Nextcloud path:
files/Photos/2021/11/IMG_5590.HEIC
File size:
675576 bytes
Database:
SELECT fileid, path, mimetype, size, mtime
FROM oc_filecache
WHERE path LIKE '%IMG_5590.HEIC';
Result:
fileid: 295274
path: files/Photos/2021/11/IMG_5590.HEIC
mimetype: 31
size: 675576
The actual file exists:
/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC
ImageMagick can read the HEIC file
I tested it as root:
sudo identify
'/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC'
Result:
JPEG 4032x3024
4032x3024+0+0
8-bit sRGB
675576B
I also tested it as www-data:
sudo -u www-data identify
'/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC'
Same result:
JPEG 4032x3024
4032x3024+0+0
8-bit sRGB
675576B
So permissions and ImageMagick access are not the problem.
PHP Imagick can read the HEIC file
I tested PHP Imagick directly:
$f="/mnt/pool/nextcloud_data/admin/files/Photos/2021/11/IMG_5590.HEIC";
$im = new Imagick();
$im->readImage($f);
echo "format=" . $im->getImageFormat() . "\n";
echo "size=" . $im->getImageWidth() . "x" . $im->getImageHeight() . "\n";
Result:
IMAGICK HEIC READ OK
format=JPEG
size=4032x3024
I also tested:
Imagick::queryFormats("HEI*")
Result:
Array
(
[0] => HEIC
)
Therefore PHP Imagick explicitly reports HEIC support.
HEIC provider is explicitly enabled in Nextcloud
Nextcloud configuration contains:
enabledPreviewProviders:
OC\Preview\Movie
OC\Preview\MP4
OC\Preview\MKV
OC\Preview\AVI
OC\Preview\Image
OC\Preview\HEIC
And:
enable_previews = true
However:
sudo -u www-data php /var/www/nextcloud/occ preview:generate 295274
fails with:
In Generator.php line 413:
No provider successfully handled the preview generation
This is different from simply having no HEIC support at the OS level.
The provider is enabled, ImageMagick supports HEIC, PHP Imagick can read the file, and the file is valid.
Nevertheless, Nextcloud's preview generator does not successfully handle the file.
Expected behavior
For a valid JPEG:
occ preview:generate
should generate a correct preview that visually matches the original image.
For a valid HEIC file:
occ preview:generate
should generate a JPEG preview.
The Photos application should then display:
Actual behavior
JPEG
The original JPEG is valid and can be decoded and resized correctly by both ImageMagick and PHP GD.
Nextcloud returns HTTP 200 and a JPEG from the Photos preview API, but the displayed image can be an essentially featureless gradient/blur rather than the actual photograph.
HEIC
Nextcloud fails to generate the preview:
No provider successfully handled the preview generation
As a result, HEIC thumbnails/previews and large image display are broken.
Additional observations
The public hostname configuration has also been tested.
Local request:
http://192.168.0.102/
works.
Public request:
https://nextcloud.circuitwater.com/
also works and returns the normal Nextcloud login redirect.
The public URL correctly uses HTTPS:
overwrite.cli.url = https://nextcloud.circuitwater.com
A test through the public hostname showed:
HTTP_HOST=nextcloud.circuitwater.com
HTTPS=
SERVER_PORT=80
REQUEST_SCHEME=http
REMOTE_ADDR=127.0.0.1
while the Nextcloud configuration test correctly showed:
overwrite.cli.url='https://nextcloud.circuitwater.com'
overwritehost='nextcloud.circuitwater.com'
overwriteprotocol='https'
Therefore I do not believe the preview problem is caused by the public URL/reverse proxy configuration.
Direct LAN requests reproduce the relevant behavior as well.
Possible relation to Nextcloud 34
This appears to be a regression in the Nextcloud 34 preview subsystem.
There is already a closely related upstream issue:
Nextcloud Server #62546 — "Cannot generate previews for heic files since upgrade to 34.0.2"
That report describes HEIC preview generation failing after upgrading to Nextcloud 34.0.2, on Debian/Ubuntu with PHP 8.5, Apache and ImageMagick. GitHub
There is also Nextcloud Server #62802 — "Imagemagick preview providers are disabled", which reports preview generation problems in Nextcloud 34 involving ImageMagick-based providers. GitHub
My environment and symptoms appear closely related, but I am also seeing the additional JPEG preview corruption described above.
What I have already ruled out
I have tested the following:
Questions for the Nextcloud developers
Could you please confirm whether this is a known regression in Nextcloud 34.0.x?
In particular:
I would prefer to avoid manually modifying the preview database or preview files because the issue affects normal Nextcloud preview generation and appears to be reproducible with valid image files.
Minimal reproduction
For the HEIC issue, the most direct reproduction on my system is:
sudo -u www-data php /var/www/nextcloud/occ preview:generate 295274
Expected:
preview generated
Actual:
No provider successfully handled the preview generation
Environment:
Nextcloud 34.0.3
PHP 8.5.8
Apache 2.4.68
Debian
MariaDB
Preview Generator 5.14.0
Imagick + GD + EXIF
HEIC support available in Imagick
Relevant commands/results
php -v
PHP 8.5.8 (cli)
php -m | grep -iE 'gd|imagick|exif'
exif
gd
imagick
sudo -u www-data php -m | grep -iE 'gd|imagick|exif'
exif
gd
imagick
sudo -u www-data php -r '
print_r(Imagick::queryFormats("HEI*"));
'
Array
(
[0] => HEIC
)
sudo -u www-data php /var/www/nextcloud/occ preview:generate 295274
No provider successfully handled the preview generation
Note: I am reporting this as a bug/regression rather than asking for configuration help, because the underlying image files can be decoded successfully by the same user (www-data) and the corresponding Nextcloud preview provider is explicitly enabled.
GitHub