In the systemd service unit template for cryptpad, there is this comment and configuration relating to open file limits
# systemd sets the open file limit to 4000 unless you override it
# cryptpad stores its data with the filesystem, so you should increase this to match the value of `ulimit -n`
# or risk EMFILE errors.
LimitNOFILE=1000000
However, running ulimit -n from within a regular SSH session as the root or cryptpad user on a modern Debian system (Trixie in this case) reports a limit of 1024.
In 2025 this reported ulimit -n value reports only the soft limit constrained by PAM for that specific login session. It seems from digging that this soft limit is inherited from a kernel default somewhere way down the stack.
In any case, that reported nofile limit doesn't constrain the nofile limit that the cryptpad systemd service has because it is launched as a systemd service at boot.
Limits set in /etc/security/limits.conf or /etc/security/limits.d/*.conf are ignored.
This is all to say that this comment in the systemd service configuration for cryptpad led us way down a misleading rabbit hole, and I'm wondering if the comment should be changed or even removed.
Please let me know if I'm misunderstanding something!
