I have NextCloud installed as a Snap on an Ubuntu 22.04 server running headlessly in an isolated network. (No internet access.) I tried to update the current NextCloud version (24.0.3snap1) to the next major version (25.0.10snap1) using these commands...
nextcloud.occ maintenance:mode --on
snap ack ./nextcloud_37355.assert
snap install ./nextcloud_37355.snap
...but the "pre-refresh hooks" hang and then fail with an error
- Run pre-refresh hook of "nextcloud" snap if present (run hook "pre-refresh": Unable to refresh: apps.nextcloud.com seems to be down, please try again later)
It seems this may be related to a recent change in how the snap detects/requires the app website's availability: https://github.com/nextcloud-snap/nextcloud-snap/issues/1485 ...but my server's always been offline and updated manually. I do not need nor want this "feature" of the update process. Some of my settings were very difficult to get right and I have a lot of user data for different users. I don't want to risk a complete uninstall/reinstall just to circumvent this "feature". Is there any other way?
UPDATE: TL;DR: If you already have Nextcloud snap installed in your offline environment,backup whatever you have to (configs, certs, maybe user data to be safe), uninstall your current version, then install the latest version.
This is an unfortunate answer, but the hooks are called for the version that you have currently installed. So, if you're in the same state as me, you are already in a bad spot. Don't try to replace the snap file that's already installed (with a signature that matches a trusted snap-maintainer cert). Just avoid the failz, backup and start over.
If you plan to keep updating that snap, keep reading for a solution that (for the future) would let future versions not need a complete uninstall (unless a snap maintainer sees the light between now and then)....
Unfortunately, this problem has two issues that exacerbate other means to fix the problem:
appstoreurl
and appstoreenabled
) so you cannot alter your config.php
to go to your appstore or a "fake" appstore nor disable this altogether.So the only way to fix this situation is to unpack the snap and remove the code from the git commit mentioned in OP. Then repack the snap and install it as a "dangerous" snap (since it won't be signed by the official maintainers.
A quick example would be:
snap download nextcloud --channel=25
Repeat this for every major version between your current version and the actual latest version, replacing "25" there with each version...
Then unpack squashfs in the snap, modify the problem file, repack the snap, install...
snap download nextcloud --channel=25
unsquashfs nextcloud*.snap
rm -f nextcloud*.snap
sed -i -e 's/if . curl.*/if false ; then/' -e 's/if occ.*app.update.*/if true ; then/' squashfs-root/snap/hooks/pre-refresh
snap pack squashfs-root
snap install ./nextcloud*snap --dangerous
rm -f ./nextcloud*snap
## repeat for each major version
EDIT: added another sed command to remove the other problematic conditional statement...
The Nextcloud documentation for manual installs does not have the requirement to check for an app store nor does it require updating apps before trying to upgrade Nextcloud itself. All the more, Nextcloud already has its own behavior for disabling and re-enabling apps during the upgrade process or trying to notify users that extra steps need to be done for specific apps (seemingly just for third-party apps that behave strangely).
Since the pre-install hook has multiple conditional statements around using an app store, is not written with good logic, ignores running configs, could have the same effect if a user just runs nextcloud.occ app:update
after upgrade...and since the additions to the hooks file seem to cause unnecessary problems, I believe there are no issues removing or nullifying these lines until someone makes more rational commits to the snap.
Snaps are important to anyone working in network enclaves or private networks because they greatly alleviate the need to manually install every dependency and dependencies of dependencies when open internet access is not available. The choice to make arbitrary extra decisions that cause havoc to use-cases that the originally accounted for...is just a reckless decision.