Fixs permission recursive in paperless chart

[faan11]

Hi,

This merge requests fixs the paperless initialization by avoiding the recursive permission that is quite slow on Truenas Scale. The solution can be found also here: paperless-ngx/paperless-ngx#5086
This merge requests increases the version from 1.2.43 to 1.2.44

[stavros-k]

Hello, changes should only happen under ix-dev directory. Also do not manually update catalog.json, it is automatically generated.

Now regarding the functional change, have you tried opening a bug report on the upstream so all downstreams get the fix? If I understand correctly, it does not apply the groupmod, regardless of the message that is being printed. (So that sounds like a bug that upstream should fix. Either the functionality or the wording).
If there is such bug report, what is the outcome of it?

[faan11]

Hi @stavros-k
thank you for you feedback, i did not know that, i'll try to fix that manually.

As you read in the discussion, this issue is not related to upstream. The upstream fixes permission in the frontend folder. This operation is usually fast on a raspberry pi ( i tried that ), but if you try that on a truenas system, is slow. This slowness will lead the deployment to timeout.

Should you have any more question or doubt, let me know

Thank you again,
Kind regard
Fabio

[stavros-k]

As you read in the discussion, this issue is not related to upstream. The upstream fixes permission in the frontend folder. This operation is usually fast on a raspberry pi ( i tried that ), but if you try that on a truenas system, is slow. This slowness will lead the deployment to timeout.

The issue here is not TrueNAS exactly, but any system using overlayFS as a storage driver would have this issue.
This is noticeable on systems with HDDs, SSDs are recommended for using apps, at least for the apps dataset.

But I still don't get why we need this change.
This will still chown and usermod/groupmod (which also does a chown btw) right before the entrypoint.
While this running, the timeout still counts.

I'd be more happy to increase the timeout like we did on NginxProxyManager, instead of overriding entrypoint.

In an ideal scenario paperless would run rootless, or at least would have a env var to skip chown at startup.

[faan11]

The issue here is not TrueNAS exactly, but any system using overlayFS as a storage driver would have this issue.

This is noticeable on systems with HDDs, SSDs are recommended for using apps, at least for the apps dataset. Yes, I'm using only HDDs. I did not thought about it. SSDs are fast but HDD are not that slow.

But I still don't get why we need this change.

This will still chown and usermod/groupmod (which also does a chown btw) right before the entrypoint. Yeah but the workaround only does two chown. The default entry point does a recursive chown for an unknown reason ( confirmed also by paperless-ngx/paperless-ngx#5086 (reply in thread) , operation: https://github.com/paperless-ngx/paperless-ngx/blob/ff4203938b954dbe4ea3f64333eeb03795887c55/docker/docker-entrypoint.sh#L13 ). This operation takes more than 6 minutes which is is not reasonable, IMO. I changed my mind. I think the addition of a new env flag in the upstream application is a proper solution. This environment var disable the usermod behaviour when it is enabled. This does not solve the main issue ( the slowness of a recursive chown ) but at least does not add a patches that depends on the upstream behavior. What do you think? If it is ok for you, we can close this issue and I'll open a pull request in the upstream. Thank you again Il 10 luglio 2024 19:16:17 CEST, Stavros Kois ***@***.***> ha scritto:

…

> As you read in the discussion, this issue is not related to upstream. The upstream fixes permission in the frontend folder. This operation is usually fast on a raspberry pi ( i tried that ), but if you try that on a truenas system, is slow. This slowness will lead the deployment to timeout. The issue here is not TrueNAS exactly, but any system using overlayFS as a storage driver would have this issue. This is noticeable on systems with HDDs, SSDs are recommended for using apps, at least for the apps dataset. But I still don't get why we need this change. This will still chown and usermod/groupmod (which also does a chown btw) right before the entrypoint. While this running, the timeout still counts. I'd be more happy to increase the timeout like we did on NginxProxyManager, instead of overriding entrypoint. In an ideal scenario paperless would run rootless, or at least would have a env var to skip chown at startup. -- Reply to this email directly or view it on GitHub: #2640 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[stavros-k]

Adding the env upstream would be ideal yes.

As for the slowness, its "expected" behavior from the overlayFS, because when you manipulate the ephemeral layers of the image, it has to copy every layer on a new mutable layer before modifying which consumes a lot of IO.

[faan11]

Thank you, I was expecting that the final layer ( result of merging all layers ) was partially cached in memory. Do you have any documentation reference for this? It's an interesting topic

[stavros-k]

Thank you, I was expecting that the final layer ( result of merging all layers ) was partially cached in memory. Do you have any documentation reference for this? It's an interesting topic

https://github.com/docker/docs/blob/3ec9c7dc1db5f355a7bde794baecc06ee24868be/content/storage/storagedriver/overlayfs-driver.md#modifying-files-or-directories