[Bug] I cannot update Nexcloud, "Update not avaliable"

[AmadeusGraves]

Describe the bug

There is something wrong, some time ago in CasaOS version 0.4.4.4, there was a problem with the application update issue due to the order of the services, this is the issue, #1259.

But now it happens again, but the order of services is correct and this has started to happen since I upgraded to CasaOS version 0.4.4.1.

To Reproduce

Steps to reproduce the behavior:

1. Go to Nextcloud App
2. Click on Update
3. No update avaliable.

Expected behavior

Nextcloud should have been updated to the new version.

Screenshots

Desktop (please complete the following information):

 - OS: Ubuntu 22.04 LTS
 - Browser Chrome
 - Version 115.0.5790.110 (Build oficial) (64 bits)
 - Docker version 24.0.5, build ced0996

Logs

Run following command to collect corresponding logs:

sudo journalctl -xef -u casaos-app-management

ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.624+0200        info        App does not have x-casaos extension - skipping        {"app": "jellyfin", "func": "service.(*ComposeApp).StoreInfo", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/compose_app.go", "line": 71}
ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.627+0200        info        App does not have x-casaos extension - skipping        {"app": "nextcloud-db", "func": "service.(*ComposeApp).StoreInfo", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/compose_app.go", "line": 71}
ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.627+0200        info        App does not have x-casaos extension - skipping        {"app": "nextcloud", "func": "service.(*ComposeApp).StoreInfo", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/compose_app.go", "line": 71}
ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.627+0200        info        App does not have x-casaos extension - skipping        {"app": "nextcloud-cron", "func": "service.(*ComposeApp).StoreInfo", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/compose_app.go", "line": 71}
ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.627+0200        info        app not found in any appstore        {"id": "Nextcloud", "func": "service.(*AppStoreManagement).ComposeApp", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/appstore_management.go", "line": 390}
ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.627+0200        info        Using default appstore        {"func": "service.(*AppStoreManagement).ComposeApp", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/appstore_management.go", "line": 397}
ago 07 15:01:13 graves-vault casaos-app-management[6483]: 2023-08-07T15:01:13.627+0200        error        store compose app not found, thus no update available        {"storeAppID": "Nextcloud", "func": "service.(*ComposeApp).IsUpdateAvailable", "file": "/home/runner/work/CasaOS-AppManagement/CasaOS-AppManagement/service/compose_app.go", "line": 181}

Additional context

Yaml exported from Nexcloud CasaOS App

name: nextcloud
services:
  nextcloud:
    cpu_shares: 90
    command:
      - apache2-foreground
    container_name: nextcloud
    depends_on:
      nextcloud-db:
        condition: service_started
    deploy:
      resources:
        limits:
          memory: 15859M
    environment:
      - PHP_MEMORY_LIMIT=2048M
      - PHP_UPLOAD_LIMIT=512M
    image: nextcloud:latest
    labels:
      icon: https://cdn.jsdelivr.net/gh/IceWhaleTech/CasaOS-AppStore@main/Apps/Nextcloud/icon.png
    ports:
      - target: 80
        published: "43920"
        protocol: tcp
      - target: 443
        published: "43923"
        protocol: tcp
    restart: unless-stopped
    volumes:
      - type: bind
        source: /mnt/vault2/BigAppData/NextCloud
        target: /var/www/html
    devices: []
    cap_add: []
    network_mode: bridge
    privileged: false
  nextcloud-cron:
    cpu_shares: 10
    container_name: nextcloud-cron
    depends_on:
      nextcloud:
        condition: service_started
    deploy:
      resources:
        limits:
          memory: 15859M
    environment:
      - NEXTCLOUD_CONTAINER_NAME=nextcloud
      - NEXTCLOUD_CRON_MINUTE_INTERVAL=10
    image: rcdailey/nextcloud-cronjob:latest
    labels:
      icon: https://cdn.jsdelivr.net/gh/IceWhaleTech/CasaOS-AppStore@main/Apps/Nextcloud/icon.png
    restart: unless-stopped
    volumes:
      - type: bind
        source: /var/run/docker.sock
        target: /var/run/docker.sock
      - type: bind
        source: /etc/localtime
        target: /etc/localtime
    ports: []
    devices: []
    cap_add: []
    command: []
    network_mode: bridge
    privileged: false
  nextcloud-db:
    cpu_shares: 90
    command:
      - postgres
    container_name: nextcloud-db
    deploy:
      resources:
        limits:
          memory: 15859M
    environment:
      - POSTGRES_DB=nextcloud
      - POSTGRES_PASSWORD=nextokcsdl
      - POSTGRES_USER=nextcloud
    hostname: nextcloud-db
    image: postgres:14.5
    labels:
      icon: https://cdn.jsdelivr.net/gh/IceWhaleTech/CasaOS-AppStore@main/Apps/Nextcloud/icon.png
    ports:
      - target: 5432
        published: "5435"
        protocol: tcp
    restart: unless-stopped
    volumes:
      - type: bind
        source: /DATA/AppData/PostgreSQL-nextcloud
        target: /var/lib/postgresql/data
    devices: []
    cap_add: []
    network_mode: bridge
    privileged: false
x-casaos:
  author: self
  category: self
  hostname: ""
  icon: https://cdn.jsdelivr.net/gh/IceWhaleTech/CasaOS-AppStore@main/Apps/Nextcloud/icon.png
  index: /
  port_map: "43920"
  scheme: http
  store_app_id: Nextcloud
  title:
    custom: Nextcloud

[AmadeusGraves]

It seems that after upgrading to version 0.4.4.1, it doesn't pick up the docker compose that was imported in version 0.4.4. Or something like that.

[WisdomSky]

Using latest and hoping that clicking Check then update will work, sadly that will not be the case.

See https://github.com/IceWhaleTech/CasaOS-AppStore/issues/167

[AmadeusGraves]

@WisdomSky thanks man, i'll change the compose from latest to a tag but i have one last question, if you have to specify a version tag then the funcionality of 'check then update', what it is for, because if you specify a particular tag, you can no longer use the update functionality because you have a particular tag. I don't know if I'm making myself clear.

[AmadeusGraves]

@tigerinus One question, if now we have to put a specific tag and not the latest, apart from what I have commented with @WisdomSky. In case a new tag comes out for example, Nextcloud, in CasaOS you can not modify the tag. That is, if you have set 'nextcloud:25.0' and you want to modify it to 'nextcloud:25.0.9' to update it, in CasaOS you can't do that, it blocks it. I think we should look for an alternative.

[WisdomSky]

@AmadeusGraves if you want your nextcloud to be able to be updated to newer versions everytime there's a new update, you might want to consider using the nextcloud from this appstore:

https://github.com/WisdomSky/CasaOS-LinuxServer-AppStore

This custom appstore constantly checks for updates and update the repository accordingly, so when you click the "check then update", it will work.

[AmadeusGraves]

@tigerinus I will summarize it to make it clearer. If you prevent you can use the tag 'nextcloud:latest' and you have to use a particular tag like 'nextcloud:25.0.9'.

--> You can't edit the app tag in CasaOS afterwards, so, you can't change version from the app.

--> If it is a particular tag, for example, 'nextcloud:25.0.9', which is deployed. Then the 'check then update' functionality will not work because it is always pointing to a particular tag. This locks the functionality and renders it useless, because you will never upgrade to a higher version.

Considering all of the above, then, you can't update the containers through the application. You would have to go back to using something like Watchtower.

I don't know if you follow me. Maybe I could be wrong and there might be a way, in that case, let me know, thanks.

[AmadeusGraves]

Ah sorry @WisdomSky, I hadn't seen your comment.

Well yes, it could be done that way, but that leaves you unable to update custom containers.

That is, if there is something you want to install and it is not in the catalog, then you would have the problem of not being able to update the container through the application.

This makes the custom installation functionality useless.

Also, catalog applications such as Nextcloud do not have a database or cronjob configured.

[WisdomSky]

@AmadeusGraves not including a database in nextcloud was intentional by design to give flexibility to users to use their preferred database. MariaDB and Postgres are available as separate applications.

There's nothing else we can offer at this point if you prefer your current setup.

[AmadeusGraves]

Finally I must comment and this is a personal opinion. The 'custom installation' and 'check then update' functions, I think they are the pillar of CasaOS, you can not always rely on application catalogues, that is optional, as they are templates that will not always work and will not always be complete as for example Nextcloud, because it has thousands of combinations, you can use different databases, you can add a server 'collaborate online', etc... as you said @WisdomSky

That's why the 'custom installation' is the one that makes the most sense and, with its 'check then update' functionality, to have the containers at the latest version or at least allow editing of the image afterward.

If you focus CasaOS to the application catalogs, then there will be no difference with TrueNAS SCALE.

I repeat, this is only a personal opinion. I don't want my opinion to be misunderstood, I'm just commenting that the direction being taken is more restrictive when it comes to installing applications and may not be the right direction.

In fact, @WisdomSky, I hope you can communicate this, I think you are part of the CasaOS team, right?

Because there are already apps that have this same design like Umbrel and I don't think it's the right way to go.

[tigerinus]

Same issue as

• 1274

?

[WisdomSky]

@AmadeusGraves I understand your frustrations as I've been previously on the same boat. I've asked them this exact question as well.

Why not using latest tag instead of specific tags? and they did bring up some good points that would benefit specially users with low bandwidth.

(P.S. I forgot which thread we had this discussion).

In fact, @WisdomSky, I hope you can communicate this, I think you are part of the CasaOS team, right?

I'm not part of the CasaOS team. I'm just regular dude who contributed back some small things.

[ETWang1991]

@WisdomSky @AmadeusGraves Is this the way you want it?

[WisdomSky]

I think it'd be best if we keep it simple. Giving options to users will only complicate things.

What I think is, just add logic to treat apps which used latest tag differently, if the app uses the latest tag and does a "check then update", what will happen is that casaos will attempt to pull the image's latest tag from remote/registry. and then compare the hash/digest with the currently running container's image. and if the hash doesn't match it means the image has been updated and so then start transitioning the app into the latest pulled image by recreating the container using the latest pulled image.

As far as I know, this is how Portainer does it when you update a container that uses the latest tag.

---

As for apps that uses specific tags (like the most of the apps that's on the appstore right now) treat it just like how we currently treat it... which is to compare the version from the appstore repo.

[Gaitmanh]

If you go to settings, and than change the cpu shares from low to medium or whatever and press save the app wil update. if you have used the latest tag

[ETWang1991]

I agree with your idea of keeping it as simple as possible, if it's ok to do so as follows @WisdomSky

[AmadeusGraves]

Sorry, @WisdomSky @tigerinus @ETWang1991 @Gaitmanh, I'm in diferent timezone. @ETWang1991 has described the use case perfectly, I think this would solve the problem.

With this change, the custom docker compose with latest tag can be updated and thanks guys for the quick response.

[AmadeusGraves]

@ETWang1991 @tigerinus , I was thinking and the use case could be simpified.

you could have two options , "store" and "custom" , the custom option will englobe the latest and custom tag. With this, you allways have to check the update in custom tag or use the store tag. Why i said this , well, because you can specify shortened tags. For example, if you specify postgresql:14 this will download the image of postgresql 14.8 but if there is a new update, for example, postgresql 14.9 in dockerhub. You have to be able to download the image of postgresql 14.9 with the tag postgresql:14 specified in the CasaOS app.

[AmadeusGraves]

@ETWang1991 @tigerinus , So this could be simplified with only two options, custom and store, the custom always download the image without check and the store will do as always.

I think this could be more simple and easy to develop.

[ETWang1991]

Got it, it does sound more reasonable cc@jerrykuku

[altShiftDev]

Pinging this thread to see if there's been any progress on this issue or any temporary workarounds? This has been going on for a while now and keeping my apps updated is important to me.

[epicfail83]

Hi, I´m facing the same "issue". I have some containers imported with docker compose using the latest tag. It´s annoying that you cannot update this containers with the "check then update" function. Pls add this in a future release.

[altShiftDev]

Hi, I´m facing the same "issue". I have some containers imported with docker compose using the latest tag. It´s annoying that you cannot update this containers with the "check then update" function. Pls add this in a future release.

Good luck. @jerrykuku has been ignoring this ticket since at least November and deleting my comments asking for updates.

[epicfail83]

Hi, I´m facing the same "issue". I have some containers imported with docker compose using the latest tag. It´s annoying that you cannot update this containers with the "check then update" function. Pls add this in a future release.

Good luck. @jerrykuku has been ignoring this ticket since at least November and deleting my comments asking for updates.

Seems so :( Any alternativ. Maybe Dockge with Dashy or similar?

[tigerinus]

Hi, I´m facing the same "issue". I have some containers imported with docker compose using the latest tag. It´s annoying that you cannot update this containers with the "check then update" function. Pls add this in a future release.

Good luck. @jerrykuku has been ignoring this ticket since at least November and deleting my comments asking for updates.

Hello @altShiftDev

I've checked with @jerrykuku and rest of the team. I believe no one has deleted any comments - it's something against of our community code of conduct and value. If it really happened, can you provide some context? What was the comment you believe that's deleted?

Regarding this issue per se - it's more of a feature change versus a bug. It's just that team members have different priorities themselves and TBH CasaOS as an open source project is currently lack of hands. However this feature is definitely in our radar still.

Once there is any news, I will keep this thread update ASAP.

[dpedrinha]

Hi, I´m facing the same "issue". I have some containers imported with docker compose using the latest tag. It´s annoying that you cannot update this containers with the "check then update" function. Pls add this in a future release.

Good luck. @jerrykuku has been ignoring this ticket since at least November and deleting my comments asking for updates.

Hello @altShiftDev

I've checked with @jerrykuku and rest of the team. I believe no one has deleted any comments - it's something against of our community code of conduct and value. If it really happened, can you provide some context? What was the comment you believe that's deleted?

Regarding this issue per se - it's more of a feature change versus a bug. It's just that team members have different priorities themselves and TBH CasaOS as an open source project is currently lack of hands. However this feature is definitely in our radar still.

Once there is any news, I will keep this thread update ASAP.

Nice.

Now all we need is an extra dev hand to implement it for us noobs. Anyone?

[jerrykuku]

Hi, I´m facing the same "issue". I have some containers imported with docker compose using the latest tag. It´s annoying that you cannot update this containers with the "check then update" function. Pls add this in a future release.

Good luck. @jerrykuku has been ignoring this ticket since at least November and deleting my comments asking for updates.

First of all apologize for the lack of updates that have been made to address this issue, also I never seem to delete anyone's comments. If it did, it was probably a misstep. I apologize profusely!

As tiger said we are indeed very short staffed at the moment, and while we have had serious discussions this week about a solution to this issue, @ETWang1991 has already given a prd for the product. We will be working on this issue later and expect to get an update in the next release.

[ETWang1991]

The team will soon make the above image app upgrade, hoping to make it simple and powerful

[epicfail83]

Thanks for the new update.....seems to work pretty well