The php module imagick is not enabled nextcloud

Hi Community,

must be install php-imagick for Nextcloud 24.0.1, but it is not aviable on Nextcloud Instans

apt install php-imagick --> not work
apt install php8.0-imagick --> not work

has someone a solution ?

Best regards,

B U S T E R

Is your problem is what is described here:

I run a the plain docker version of Nextcloud and just opened a shell in the Nextcloud app and pasted in the commands there:

# apt -y update
# apt -y install libmagickcore-6.q16-6-extra

Is your problem is what is described here:

I run a the plain docker version of Nextcloud and just opened a shell in the Nextcloud app and pasted in the commands there:

# apt -y update
# apt -y install libmagickcore-6.q16-6-extra

thanks for try to help, this i have always installed, issue is more --> "php-imagick in this instance has no SVG support"

thanks for try to help, this i have always installed, issue is more --> "php-imagick in this instance has no SVG support"

Did you read the link I posted? If you did, please rephrase the above so I can understand your problem.

Did you read the link I posted? If you did, please rephrase the above so I can understand your problem.

I had overlooked your link..
you should know that I use Nextcloud under truenas-scale, I get the following error message

Yes, this is the Truenas Scale forum, so I assumed as much.

You should not do what is described in the link. You should do what is described in my first post.

Open a shell in the App/container and execute these commands:

# apt -y update
# apt -y install libmagickcore-6.q16-6-extra

If the container is upgraded/reloaded you will need to redo this.

Yes, this is the Truenas Scale forum, so I assumed as much.

You should not do what is described in the link. You should do what is described in my first post.

Open a shell in the App/container and execute these commands:

# apt -y update
# apt -y install libmagickcore-6.q16-6-extra

If the container is upgraded/reloaded you will need to redo this.

this command i do it yes sure in App/container but after refresh site issue persist instantly

i have found a Note in Nextcloud.com FAQ --> //docs.nextcloud.com/server/1...ion.html?highlight=svg#previews-configuration

Note
Technically Nextcloud can also generate the previews of other file types such as PDF, SVG or various office documents. Due to security concerns those providers have been disabled by default and are considered unsupported. While those providers are still available, we discourage enabling them, and they are not documented.

it is Disabled sites from Nextcloud himself ore what they will tell us ?

just going to point out that running apt with in a container anyways is a little silly since next time the up stream container is updated its just going to wipe it out.

any situation where you need to add extra options to a container you should do one of 2 things

A Create build maintain and host your own container with the needed options installed
B Run the application on a Dedicated VM with all your needed options instead of using a container image.

On our App the following related packages are already installed:
imagemagick-common
libmagickcore
libmagickcore-dev

just going to point out that running apt with in a container anyways is a little silly since next time the up stream container is updated its just going to wipe it out.

any situation where you need to add extra options to a container you should do one of 2 things

A Create build maintain and host your own container with the needed options installed
B Run the application on a Dedicated VM with all your needed options instead of using a container image.

Given that this is a permanent problem, your suggestions make sense.
If you had read the link I posted you would have seen this:

This is a bug in the docker image and will likely be resolved soon – in the meantime, we can just manually install the required library on the container:

So if the official Nextcloud image is indeed fixed soon, I believe re-running apt once or twice is much preferred to creating alternate containers or VMs.

On our App the following related packages are already installed:
imagemagick-common
libmagickcore
libmagickcore-dev

Yes. If I had been starting from scratch, using Truecharts would have been the way to go.

I did upgrade to Scale from Core and had an existing Nextcloud installation, using Mariadb. So I figured using the standard Nextcloud docker image was simpler, just reusing my data-directory and database.

Given that this is a permanent problem, your suggestions make sense.
If you had read the link I posted you would have seen this:

So if the official Nextcloud image is indeed fixed soon, I believe re-running apt once or twice is much preferred to creating alternate containers or VMs.

This is incorrect information.
The link you quoted, is a statement from a random person on the internet.

We've had to apply this fix for months by now and there seems to be no activity from the people at Nextcloud on this front at all.

This is incorrect information.
The link you quoted, is a statement from a random person on the internet.

We've had to apply this fix for months by now and there seems to be no activity from the people at Nextcloud on this front at all.

By incorrect I assume you mean that it won't be fixed soon?

I did some more research and see that this has been discussed rather actively for a while:

There are some security concerns with this library, but I see that there now seems to be consensus that it should be included. One can hope.

I'm perfectly happy to live with the current situation. I have no adverse effects of the missing library, apart from the warning. And if that bothers me I just reinstall with apt in the container.

This is incorrect information.
The link you quoted, is a statement from a random person on the internet.

We've had to apply this fix for months by now and there seems to be no activity from the people at Nextcloud on this front at all.

how can you explain why the error message happens to me?
i use Nextcloud v24.0.2 from Truecharts in Truenas Scale

PS: something else where is the php.ini file stored?
i need to change max size upload file, i can't find the php.ini

how can you explain why the error message happens to me?
i use Nextcloud v24.0.2 from Truecharts in Truenas Scale

PS: something else where is the php.ini file stored?
i need to change max size upload file, i can't find the php.ini

If you have any feedback about things we build, please contact us directly.
We only have a small minor amount of staff available on this forum.

how can you explain why the error message happens to me?
i use Nextcloud v24.0.2 from Truecharts in Truenas Scale

PS: something else where is the php.ini file stored?
i need to change max size upload file, i can't find the php.ini

did you ever find a resolution to finding the php.ini file?
ive been trying to find access to the php-fpm.conf file [i believe the php.ini file may also contain the related pm.children that i need to edit [truecharts seems to have it set at 2, and according to nextcloud directly, that value should be at least 120, to exacerbate the issue, truecharts build seems to lock the package manager when in sherll and not mount that file when accessed via PVC.]

did you ever find a resolution to finding the php.ini file?
ive been trying to find access to the php-fpm.conf file [i believe the php.ini file may also contain the related pm.children that i need to edit [truecharts seems to have it set at 2, and according to nextcloud directly, that value should be at least 120, to exacerbate the issue, truecharts build seems to lock the package manager when in sherll and not mount that file when accessed via PVC.]

As explained by our staff quite a few time to you this week:
Our containers are directly supplied by Nextcloud themselves.

We do *not* block access to shell and we do *not* set the php-fpm settings. Those are the upstream settings they configured to be used.
The FPM configuration files are not part of the PVC because they are as well supplied by nextcloud themselves. [and actually partly dynamically generated].

It would be nice if you could stop spreading information which was already explained to be untrue multiple times, like your repeated comments about us locking people out of the shell. That's simply completely untrue.

The containers we do build ourselves [which is just a handfull], have full shell access. The rest are simply mirrored.

*edit*
In case you wonder, this is the ongoing upstream PR about your request:

Run TrueNAS CORE and FreeBSD jails if you want persistent transparent containers. No intention to snub SCALE, TrueCharts or Docker in general, but there are always alternatives and people with different approaches to systems.