Nextcloud: Weird smb behavior, potentially missing php module

[BlauerHunger]

I'm running the nextcloud chart on TrueNAS SCALE Cobia and I have a smb share from the TrueNAS SCALE host mounted as external storage in the nextcloud app.

The "Install smbclient" option is ticked in the app configuration, but when syncing larger files (>1GiB) from the smb mounted external storage, sync fails and the postgres log shows entries like this one:

LOG:  could not receive data from client: Connection reset by peer

Nextcloud also creates huge amounts of log entries like this one:

fseek(): Stream does not support seeking at /var/www/html/apps/files_external/3rdparty/icewind/streams/src/...

A thorough search on the internet led me to this issue report on the nextcloud server github repo: nextcloud/server#41114. I don't know what exactly causes this problem, but I was able to get it working on my system running the following inside the nextcloud pod of the nextcloud app:

apt install libsmbclient-dev
pecl install smbclient
docker-php-ext-enable smbclient
apache2ctl restart

To me it looks like the app is missing the php smbclient module and utilizes some workaround that doesn't play well with the TrueNAS SCALE smb server. Is there any chance you could include the php smbclient module in the official nextcloud chart?

[BlauerHunger]

is this issue really an enhancement? I thought the "Install smbclient" checkbox is supposed to make external storages via smb work, but apparently it doesn't work except for small files and it doesn't fail gracefully and this behaviour isn't documented for this chart.

[stavros-k]

Technically yes its an enhancement, because even the smb-client installation is more of "stop-gap" solution.
I think those kinds of dependencies should be included in the nextcloud container itself.

You could consider it a "bug" from nextcloud side, but I don't think this is correct either.
Its still an enhancement on their container.

Containers are not supposed to install packages on runtime.

Correct solution would be to have pre-build container will all the required packages. But then you also get to the other side, that you make everyone download an image that has packages that will never need (and potentially more "things" that might have vulns at some point).

I'm not opposed to making this work correctly, but we need to find a better solution.

[pabloeisenhut]

Technically yes its an enhancement, because even the smb-client installation is more of "stop-gap" solution. I think those kinds of dependencies should be included in the nextcloud container itself.

You could consider it a "bug" from nextcloud side, but I don't think this is correct either. Its still an enhancement on their container.

Containers are not supposed to install packages on runtime.

Correct solution would be to have pre-build container will all the required packages. But then you also get to the other side, that you make everyone download an image that has packages that will never need (and potentially more "things" that might have vulns at some point).

I'm not opposed to making this work correctly, but we need to find a better solution.

@stavros-k can you please have a look at nextcloud/docker#2186 (comment), maybe this is a solution for some existing problems described with #2123 (comment).
This is not (yet) a solution for the SMB behavior as far as I understand correctly, but for the problems referred to here. For example #2298.