-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: TypeError: Return value of OCA\DAV\Connector\Sabre\FilesPlugin::OCA\DAV\Connector\Sabre\{closure}() must be of the type int or null, float returned #34674
Comments
Thank you for taking the time to report a bug! 👍 As this seems to be a setup issue I would like to ask you to raise your question in the forums: https://help.nextcloud.com |
As for the admin link, thanks for reporting! We'll look into it! |
I don't think this is a setup issue, the Nextcloud instance has been running fine for about 3 years until this happened. I also opened a question in the forum as you suggested, and there seem to be more people having this issue on a Raspberry Pi. Another user found out that users created after the upgrade are not affected by the issue |
This is a setup issue and only happening since you are still running some 32bit components. |
Sadly I can't upgrade my Raspberry to 64 bit anytime soon (I have a lot of other stuff running on it, so it wouldn't be a simple backup, reinstall & recover). To prevent this from happening to other 32 bit users, there should be at least a warning before the upgrade mentioning the platform deprecation. |
I agree. Will look into that in the next days. Just so that you know:
|
Could the System Requirements page be updated to reflect that 64bit only is supported: This currently implies that 64bit is recommended and 32bit will work but not that well - not that it will be totally broken: CPU Architecture and OS |
I followed the decision to formally drop 32-bit support as of long standing issues with the trashbin and >2 GiB file downloads from web interface on 32-bit systems. I test the beta on my Raspberry Pi 2 v1.1 (32-bit CPU) production system nearly every time beforehand, sadly not this time, otherwise I could have brought up the topic earlier. There is a workaround, but such on the trashbin causes other issues (AFAIK >2 GiB overall trashbin data worked with it, but individual >2 GiB files didn't work, or so), which likely is similar here with the DAV connector. Users created after the upgrade likely don't have the issue because/until they have >2 GiB of files 😉. I guess there are no plans to revert the change to make files app and sync work again? Because then we quickly need to disable our Nextcloud install option on DietPi for 32-bit architectures for release tomorrow 😉. |
|
Here btw is the culprit: nextcloud/3rdparty@dd3f5da#diff-15aea57cf25666fcad29ed4fc1ba78e5d8e447c574a877bb4fdc9cb87e5ff4b2
A related This individual change could in theory be reverted? At least for users which are currently stuck with 32-bit hardware this would be safer than applying the workaround I linked above so that a function returns a float instead of the expected integer. |
The related PR explicitly mentions Nextcloud and states that this workaround in sabre/http code wouldn't be required anymore: sabre-io/http#184 Would be more than a coincidence if this was right but NC files app+sync still broken in the release this was merged 🤔. |
Seems like they have the same problem: Their CI also does not runs against 32-bit so they could not have found this issue without testing it manually... |
I have the same issue with the same configuration of @maxicarlos08 |
All expected on every 32-bit system. Please see the linked workaround above or migrate hardware+OS to 64-bit. |
@MichaIng I was just hit by this issue (i.e. In detail: I have been running Nextcloud 24.0.6 for quite some time now without any issues (expect for #15117). And after reverting from Now I am running Nextcloud on an Odroid HC-2 (armv7, so 32 Bit only). I'd be happy to help debugging if needed. EDIT: For completeness:
|
Thanks for the hint, you're right, also the So we need to have a deeper look into how |
- DietPi-Software | Nextcloud: Disable for 32-bit ARM for now, as core functionality is broken with NC25: nextcloud/server#34674 - DietPi-Software | FuguHub: Do no overwrite /home/bd/tuncnstr.dat on reinstalls
Not sure how I could have overseen it, here the PR which added int type hint: 829490a#diff-1d6ed4804160da213bc58248990a6936622ce53100a23535d207dba153f7e759 I guess it's either reverting best practise type hint or accepting 32-bit support now has really gone. |
I also have this problem and would greatly appreciate a fix for 32bit Operating Systems to avoid unnecessary hardware replacements and to save resources (apart from the time needed to setup everything fresh again, which would cost me days). |
@Slartibartfast27 there is a fix at https://help.nextcloud.com/t/cannot-access-files-after-upgrade-to-nextcloud-25/147823/6?u=michaing And I hate to be that guy, but imho you really should rethink your backup/rollback strategy. Something like this can happen, all the time. And recovering from it should be not more than a minor inconvenience. |
@MichaIng About dropping 32 bit support: I think that is a bad idea. I agree, that corporate users won't mind: they are all on 64 bit by now. But home users aren't - I for one am not. I agree, that there is no x86 32 bit machine worth keeping alive - they are at best a waste of energy. But that argument does imho not hold for ARMv7. There are still a lot of ARM 32 bit computers able to run Nextcloud for friends and family. |
If 32bit support is dropped though it should be properly documented not just a vague 64bit is recommended. The commit has actually broken 32bit support so it isn't just recommended it is required. |
Most importantly the update to NC25 should then not be offered on 32-bit systems. Generally on this matter: I agree if there are no strong reasons, at least this core functionally should be preserved on 32-bit. The change was a best practice annotation from lint, not related to any actual issue, AFAIK. However, there were other long standing issues with 32-bit (>2 GiB trashbin, >2 GiB downloads) and the CI/CD pipeline does not contain 32-bit tests (runs on 64-bit), so such issues can slip through any time later, if not someone with 32-bit system tests the beta/RC. Sadly I didn't do it exactly this release while always tested new NC releases beforehand before. |
Yes, that would be a good idea indeed. But from how I understand this piece of code it is currently not possible to filter specific architectures when fetching updates? So I don't see how we could prevent 32 bit NC24 users to upgrade.
Never ran into the first one, but I - long time ago - tried to get a fix for large downloads merged (see #15117 and #27562) and it was rejected back then. The patch still applies (including NC25) and still fixes the issue, which is afaik. still (i.e. more than a year after) present on 32 bit. I can't seem to find the proposed "option for specifying the archive format" on my NC 24. So please understand my saltiness on the "32 bit has problems" topic.
There may still be the option to have them running inside a Docker container - Debian still offers 32 bit x86 images. I quickly threw together something at https://github.com/j-be/nextcloud-ci/. There are still a couple of test failures even on AMD64 - not sure why. But there are definitely a lot more in the NC25 386 run (see https://github.com/j-be/nextcloud-ci/actions/runs/3369893196). So even if GitHub does not provide 32 bit runners: there may still be ways to get 32 bit CIs with GitHub Actions. I think the question that needs to be answered is: Will the Nextcloud team put effort into keeping 32 bit supported or not. And imho. this decision then needs to be communicated to the community. "Not recommending" 32 bit (EDIT: and recommending to switch to a 64 bit OS) is all nice and good, but for people like me, who are running 32 bit hardware that recommendation is of no use. |
That is true, although based on PHP_INT_MAX it wouldn't be so hard to implement.
That decision has been made with officially requiring (according to docs, not only "recommending") 64-bit, I guess: https://docs.nextcloud.com/server/latest/admin_manual/installation/system_requirements.html#cpu-architecture-and-os So given that any other solution than reverting int type hint is likely much more effort, to me the question is whether to revert this for a while and implementing an arch-based update blocker later and communication via e.g. also admin panel warning is better than adding the blocker directly. Or letting users run into the issue and finding the workaround 😅. I'm actually surprised about the low number of users participating here (though there are some other related issues open). |
Hello @j-be , thanks for the link to the fix ;-) This worked also for me. BUT: I primarly use the calender. Sometimes I don't use files for weeks. So it might happen, that I do not recognize a problem with files for weeks, which makes a rollback barely impossible without loosing potentially weeks of calendar changes. From my perspective it would be ideal, if nextcloud would not start at all anymore if the system is not compatible. Then it would be easy to rollback. |
With next Nextcloud 25.0.2, 32-bit will work again, and the upgrade blocker to v26 is already in place: c124456 |
I also only today observed that the file sync was broken after recently upgrading to 25.0.1... I am looking into an upgrade to 64bit hardware as well, but this will take some more month to happen (I run nextcloud on my NAS) |
Thanks a lot for fixing this, it took me some time to find out what the issue was. I don't plan to upgrade my hardware (armv7l, as most of us) any time soon, so really hoping for a 32 bit LTS NC 25... :) If it needs some paid subscription to be viable, let me know and I surely would consider. |
Great. NC v25 (updated from 24.0.7.1 to 25.0.1.1 already following my personal https://nextcloud.com/blog/press_releases/nextcloud-hub-3-release-ai-photos/ ...but informing admin users in advance of an update (not to think of blocking/not showing the update, that on the apps level hasn't been merged until today) that the system does not meet the requirements... nope! Same BS like with single apps now happens for the core too. Thankfully the workaround / future fix seems to work for now and buys important time for making migration plans - that will be at least a full weekend, possibly even 3 to 4 full days just thinking of what else is running on my Nextcloud Pi.
Summary: If both parts contribute, updates will not end up in total desasters. Looking that the fix https://github.com/nextcloud/server/pull/34905/files will be shipped with NC v25.0.2, I might tweak my I would appreciate a 32 bit LTS version too, but I don't think that is gonna happen. Instead, now having time until October 2023 according to https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule (EOL of NC v25) and assuming, NC v25 will continue to work on 32 bit OS/platforms (⚠ confirmation please ⚠), that should be enough time to reinstall with a 64 bit OS. |
Problem still here : #34905 (comment) Maybe this should be reopened ? |
The issue when using a quota did not exist before NC25? |
It did not. |
PR up: #35832 |
Replaced by #35734 Thanks a lot ! |
Bug description
After upgrading to Nextcloud version 25 today, I was unable to view my files getting this error:
Steps to reproduce
Expected behavior
I expect the file app to work normally
Installation method
Community Manual installation with Archive
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
I'm running Nextcloud on a 64 bit raspberry pi 4b, however
https://server.url/settings/admin/overview
tells me that:The text was updated successfully, but these errors were encountered: