LibreSign
Invalid hash for aarch64 Java binary on Nextcloud 31
Describe the bug
Invalid hash for aarch64 Java binary on Nextcloud 31
To reproduce
Hello,
I am running Nextcloud on an aarch64 (ARM64) server and am unable to get LibreSign to validate its dependencies.
Problem:
The setup page shows an "Invalid hash of binaries files" error for the java resource. This prevents the jsignpdf dependency from working as well.
Steps Taken:
I have run the occ libresign:install --all command inside the Docker container. The command line reports "Finished with success" after downloading the java aarch64 linux... binary. However, the error in the Nextcloud UI persists even after re-validating.
This indicates that the hash of the downloaded aarch64 Java binary does not match the expected hash in the app's source code.
I am attaching screenshots of the UI error and the successful terminal command output.
Thank you!
Expected behavior
No response
Screenshots
Environment information
- OS: Ubuntu 24.04 LTS
- Architecture: aarch64
- Installation: Nextcloud via Docker (on CapRover)
- Nextcloud Version: 31.0.0
- LibreSign App Version: 11.4.1
Additional context
No response
Hello, could you check your nextcloud.log file if is registered any entry about LibreSign when you try to install the dependencies?
Issue likely caused by a mismatch between the expected hash in LibreSign source and the downloaded aarch64 Java binary.
A re-validation attempt in the UI still fails.
Allow me to work on this if possible, would happily push a PR
@tusharrrr1 It's a bit complex issue, but your help will be good.
The first step is to check the logs. Every when this message is throws, is added a row at the nextcloud.log file with what's happened.
I fixed it with stable version. I used docker's latest tag. It has some bug in there. Then I reinstalled it with stable tag. It is perfect now. By the way, I used caprover to install the Nextcloud. Then I mounted the /data to different cloud storage. Because I mounted it in different storage, the dependencies are installing in that storage box not in main server's docker real volume. Then again I did transferred the /appdata_<instance_id> directory to docker's real volume. I also set the caprover's persistence directory "Path in App" to this "/var/www/html/data/appdata_<instance_id>" and Label to this "caprover default label for the app". Then use "rsync" to transfer the app data from mounted storage to server's main docker volume. Now it is perfectly working,
But I still kept the /data to the mounted storage only transferred the /data/appdata_<instance_id>