Hi @jeremy-oaks_9309,

Glad to help! Please let us know if you have any issues with the migration.

Thanks,
Rich

Hi @jeremy-oaks_9309,

After digging into this further, there are a handful of issues that have all hit here. Before I dive into these, is there a reason you chose to use InedoDB over using the embedded database? Our guidance is when using a single ProGet container, use the embedded database. InedoDB is only recommended to be used with clustered installations of ProGet.

In your case for using InedoDB and ProGet, there were basically 3 main issues that occurred.

Issue 1:
Your docker compose file is not quite correct. You currently have your volume mappings backwards which will cause your data to not be persisted through restarts. This is also why when you updated the the pg_hba.conf file, it did not persist. I should also point out there was a typo in our DockerFile, which pointed to the wrong directory for an InedoDB volume path. This is fixed in InedoDB 17.10.2. We also updated our InedoDB Docker Installation Docs to include the volume as well.

Here is a modified version of your docker compose that will fix these issues:

services:
  inedodb:
    image: proget.inedo.com/productimages/inedo/inedodb:17.10.2
    container_name: inedodb
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - /mnt/volume_nyc1_proget/postgres:/var/lib/inedodb

  proget:
    image: proget.inedo.com/productimages/inedo/proget:26.0.5
    container_name: proget
    restart: unless-stopped
    depends_on:
      - inedodb
    ports:
      - "8634:80"
    environment:
      PROGET_POSTGRES_CONNECTION_STRING: Host=inedodb;Port=5432;Database=proget;Username=inedodb;Password=<REDACTED>
    volumes:
      - /mnt/volume_nyc1_proget/proget/packages:/var/proget/packages
    deploy:
      resources:
        limits:
          memory: 2g

Issue 2:
The default for pg_hab.conf was too restrictive. This was actually updated in the Windows installer, but not in the inedodb create --name=proget command. This has now been fixed in InedoDB 17.10.2 and it will work out of the box. With that said, it is stored in a persisted volume, so changes will stay in affect. The other part of this is that when create a database, the container needs to be restarted. We have now added a message in the inedodb create command to restart the container.

Issue 3:
The connection string confusion. This is a side effect of Docker. When we generate the connection string in InedoDB, we use the get host name command from within the container. That hostname does not match the container name or network alias of the InedoDB . We have now added a warning when creating a database in InedoDB on Docker that you may need to update the host in the connection string.

With all those addressed in docs and InedoDB 17.10.2, you should be good to create a new ProGet instance with InedoDB. If you have already started adding packages using your existing setup, I would be worried that your database and package files are not persisting through restarts. I would recommend:

1. Set up a new instance using the DockerFile I used above and a trial key
2. Import your packages from that instance to the new instance
3. Shut down you old instance and move the license key to the new instance

I know this is kind of long, so if you are confused on anything or have any other questions, please let me know!

Thanks,
Rich

Hi @jeremy-oaks_9309,

Thanks for bringing this to our attention. This looks like a change will will need to make to the InedoDB container. Let me do some digging and I'll have an update for you soon.

Thanks,
Rich

Hi @joris-guex,

Thanks for sending an example over. It looks like this is related to an issue in the libssh2-sys's manifest. I have created a ticket, PG-3321, to handle these issues better. We are expecting to have a fix out within the couple of maintenance releases of ProGet 2026.

Thanks,
Rich

Hi @Nils-Nilsson,

Thanks for bringing this to our attention. This looks to be a regression that happened right before release. I have created a ticket, PG-3289, to track the fix and we will release it this Friday in ProGet 2026.2.

Thanks,
Rich

Hi @Nils-Nilsson,

We identified the issue with the UI and have fixed it in PG-3277. This will be released next week in ProGet 2026.1.

As for the UserNotFoundException after the rollback, that is most likely related to your cookies. Once the cookie expired, it then let you login again. You can verify that by using an private/incognito window and logging in or clearing your cookies and logging in again.

Thanks,
Rich

Hi @cole-brand_2889,

I have identified the issue, PG-3268, and this should now be fixed in ProGet 2025.27. Please upgrade to 2025.27 and see if that resolves your issue.

Thanks,
Rich

Hi @geraldizo_0690,

Thanks for providing all of this information. I was finally able to recreate the issue. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27. Just to make sure I cover all my bases, can you tell me which database backend you are using?

Thanks,
Rich

Hi @kien-buit_2449,

This is partially fixed in our vulnerability aggregator. You should see alpine vulnerabilities showing up next time your vulnerability updated runs. I also recreated a situation where certain packages may not be removed upon update of the vulnerability. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27.

Thanks,
Rich

Hi @sigurd-hansen_7559,

This is a known issue, PG-3246, and will be fixed on Friday in ProGet 2025.25.

Thanks,
Rich

Hi @sigurd-hansen_7559,

We can add back support to not do the recursive search. If you would like to use a search scope, we would recommend using the OpenLDAP/Generic LDAP user directory and specifying your own LDAP queries. With that said, I think that is overkill for this situation and adding a way to disable recursive groups will be the easiest. I will get that added on the April 3rd release of ProGet 2025.25.

Thanks,
Rich

Hi @sigurd-hansen_7559,

Let me start with a little background in V5 vs V4. With V5, our goal was to only support Active Directory because we have since created an OpenLDAP/Generic LDAP specific user directory. This allowed us to strip out the extra LDAP querying we had to do in V4 to support both. This significantly reduces the amount of LDAP queries to look up a user. It also allowed us to lean into specific Active Directory LDAP features that we could not do when supporting both.

One of those features we can now use is the built in LDAP query for a user's groups and a group's members. When we look up groups we use the following LDAP query:

(&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=«USER_DISTINGUISHED_NAME»))

This means that we will return all groups (including nested groups) just like how Active Directory would on Windows without having to make a circular walk of the groups tree in a single LDAP request.

Could you answer a few questions for me?

1. Is your ProGet instance running on Windows or Docker?
2. When you say significant group memberships, approximately how many are there? (~10, ~20, ~50, etc...)
3. Is your domain part of a multi-directory forest?
4. In your V4 user directory, can you change the recursive group search to "Recursive Search (Active Directory Only)" and see if you see the same slow downs?

Thanks,
Rich

Hi @gbeckett,

Glad to hear it is working for you! Please let us know if you run into any other issues.

Thanks,
Rich

Hi @gbeckett,

I just pushed out a pre-release version of ProGet 2025.24-rc.3 and can be installed via InedoHub. Please see our our guide on installing pre-release verions for more information. Please let us know if you have nay problems.

Thanks,
Rich

Hi @phil-sutherland,

Thanks for sending this over to us. This looks to be a regression in the PostgreSQL migration. I have created a ticket, PG-3241, to fix the issue. This will be fixed in the next maintenance release of ProGet 2025.24, due out on March 20, 2026.

Thanks,
Rich

Hi @gbeckett,

It looks like there was a merge issue and part of this fix was undone. I have created a new ticket, PG-3240 to fix it. If you would like, I can create a pre-release of ProGet 2025.24 with the fix that you can install now. If not, the fix will be released at the end of next week in ProGet 2025.24.

Thanks,
Rich

Hi @Valentijn,

We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available.

Thanks,
Rich

Hi @phil-sutherland_3118,

There is nothing off the top of my head that would fix this. The next step would be to see your LDAP queries and potentially some example data. It would probably be best to wait until you get a license if you do not feel comfortable sharing that data on the forums. If you care to look, you can see our code for both our AD User Directories and our OpenLDAP/Generic LDAP user directories on our GitHub repo: https://github.com/inedo/inedox-inedocore

Thanks,
Rich

Hi @sirko_6724,

Please let us know what you figure out. When we built our OpenLDAP user directory, we built it based on OpenLDAP's best practices for groups and this is the first time we have seen an issue with groups missing the member attribute. I know you are adverse to making changes to your OpenLDAP server, but another option would be to populate the users on the groups using a Dynamic List. That would allow you to add the user's dn to the group without having to change all the records.

Thanks,
Rich

Hi @phil-sutherland_3118,

Just to confirm, are you using an Active Directory domain or OpenLDAP doimain in your environment? Your initial post makes it sound like you are using Active Directory and not OpenLDAP. If you are connecting to Active Directory, you can use the following two LDAP settings to get groups and members:

• For List User's Groups: (&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=%s)) and for get a groups
• For List Group's Members: (&(objectCategory=user)(memberOf:1.2.840.113556.1.4.1941:=%s))

These will only work when using our OpenLDAP/GenericLDAP user directory and connecting to an Active Directory domain, OpenLDAP domains do not implement these special queries.

That other forums post is a OpenLDAP domain that is using custom attributes for groups.

Thanks,
Rich