Does ProGet support creating and managing local groups for users authenticated via LDAP i.e. LDAP-authenticated users, but groups defined and managed locally in the system?
Is it possible to disable import or syncing of LDAP groups when integrating with an LDAP directory?
When trying to resolve a Maven package using Gradle through a Maven feed that’s configured with a third-party registry, e.g. public Maven or internal Maven via a connector, the server responds with a 500 Internal Server Error with message: Value cannot be null. (Parameter 's')
Additional context:
How can we resolve or work around this issue?
System information:
Web UI Version: 2025.5 (Build 16)
Database Schema Version: 25.0.5.16
SQL Server Version: PostgreSQL 17.5 (Debian 17.5-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
db_owner: True
Database Name: proget
Database Collation: C (UTF8)
Database Recovery Model: Default (1)
Database Read Committed Snapshot: True
Database Auto Update Stats: True
Hi @rhessinger,
I currently do not have an overview on how many images without top-level mediaType.
To have an image in Nexus without top-level mediaType, you can use the oras CLI tool to manipulate the manifest.
For my testing, I used skopeo to copy an OCI image (e.g. alpine/git:v2.52.0) to Nexus.
skopeo copy --dest-creds <user>:<password> --dest-tls-verify=false docker://alpine/git:v2.52.0 docker://registry.nexus.example/docker/alpine/git:v2.52.0
Then I used the oras to:
fetch the manifest
oras manifest fetch --insecure registry.nexus.example/docker/alpine/git:v2.52.0 > manifest.json
Edit the manifest.json, and remove the top-level mediaType
Push the manifest back to the registry
oras manifest push --insecure --media-type application/vnd.oci.image.manifest.v1+json registry.nexus.example/docker/alpine/git:v2.52.0 manifest.json
After that, when inspecting the manifest with docker manifest inspect, the top-level mediaType should be missing from the image. And when trying to do migration in ProGet, it will show that the image is not found.
I hope the information shared above is useful. Thank you.
Hi @rhessinger ,
Unfortunately I do not have an example of Dockerfile to build the image.
However, after further investigation, I noticed that this only happens when the top-level mediaType is missing in the image when I used the docker manifest inspect <image> to check the manifest.
After I updated the manifest with top-level mediaType manually, the ProGet is able to identify the image and migrate it from the Nexus.
Hi @rhessinger ,
Thanks for the support. I am now able to import container images from Nexus.
However, I notice that images with OCI media type are not imported. Is that expected?
Output of execution:
INFO: Importing example:0.0.1...
WARN Docker image "example:0.0.1" not found.
The example:0.0.1 has the following value returned from the https://«NEXUS_HOST_AND_PORT»/service/rest/v1/components?repository=«REPOSITORY_NAME» API:
"contentType" : "application/vnd.oci.image.manifest.v1+json",
Hi ProGet team,
I was reading through the backup documentation and saw this statement:
"For smaller, single-server installations, you may find it easiest to simply take a snapshot of the Virtual Machine the product is running on. As long as all components are hosted on a single virtual machine, this will sufficiently backup the product."
Just wanted to clarify how this works in a restore scenario.
If the VM containing the ProGet docker deployment is backed up or snapshotted and later restored into a different cluster (with different underlying hardware), will ProGet work simply by starting the container services? Or are licenses tied to hardware-specific identifiers (CPU, MAC, etc.) that could cause issues after restoring the VM elsewhere?
Basically trying to confirm whether a full VM restore is enough, or if there are licensing steps needed after moving the VM.
Thank you.
Hi @rhessinger ,
Thanks for your help! I’m fine waiting until the release next Friday.
Hi @rhessinger,
I don’t think the reverse proxy strips the component API. In the configuration of the reverse proxy, we map a URL to a port, so when a client accesses the server using a specific URL, the request is routed to the corresponding listening port.
Thanks.
Hi @rhessinger ,
The pseudo-group/subgrouping/groups are just arbitrary name for possible parent groups.
This is a screenshot of the layout when the image are published to Nexus.
Thanks.
Hi @rhessinger,
Thanks for the reply. I am running Nexus 3.76.1.
Here's the response from the API:
{
"items" : [ {
"id" : "<obfuscated>",
"repository" : "docker",
"format" : "docker",
"group" : "",
"name" : "pseudo-group/subgrouping/groups/individual/project/image",
"version" : "stable",
"assets" : [ {
"downloadUrl" : "https://my-nexus-server.foo.bar.com/repository/docker/v2/pseudo-group/subgrouping/groups/individual/project/image/manifests/stable",
"path" : "/v2/pseudo-group/subgrouping/groups/individual/project/image/manifests/stable",
"id" : "<obfuscated>",
"repository" : "docker",
"format" : "docker",
"checksum" : {
"sha256" : "<obfuscated>",
"sha1" : "<obfuscated>"
},
"contentType" : "application/vnd.docker.distribution.manifest.v2+json",
"lastModified" : "2025-12-02T12:15:33.452+00:00",
"lastDownloaded" : null,
"uploader" : "<obfuscated>",
"uploaderIp" : "<obfuscated>",
"fileSize" : <obfuscated>,
"blobCreated" : "2025-12-02T12:15:33.454+00:00",
"blobStoreName" : null,
"docker" : { }
} ]
} ],
"continuationToken" : null
}
The Docker API Override URL is set to https://nexus-registry.foo.bar.baz.com/v2/ which is the URL returned by the docker client.
Here's the outputs when running the migration:
info: System.Net.Http.HttpClient.Default.LogicalHandler[100]
Start processing HTTP request GET https://nexus-registry.foo.bar.baz.com/v2/ouping/groups/individual/project/image/manifests/stable
info: System.Net.Http.HttpClient.Default.ClientHandler[100]
Sending HTTP request GET https://nexus-registry.foo.bar.baz.com/v2/ouping/groups/individual/project/image/manifests/stable
Hope the info above is helpful. Thanks!
Hi ProGet team,
Thanks for adding support to override the Docker API URL. However, during my testing, it doesn’t seem to work as expected.
For Docker images with long paths, based on the logs, it appears that the requested URL path is truncated. I’m not sure if this is just a visual effect in the logs or if the actual request is being truncated. For example, the URL should be:
https://nexus-registry.example/v2/my-example/subgroup/container/project/subname/image/manifests/stable
but the log shows:
https://nexus-registry.example/v2/group/container/project/subname/image/manifests/stable
and it returns a 404, even though I can access the original URL directly in the browser.
Furthermore, with shorter image paths, e.g.:
https://nexus-registry.example/v2/python/manifests/3.11.2-bullseye
I don’t see the request in the log, and it fails with the following error message:
Error: Unhandled exception: System.ArgumentOutOfRangeException: startIndex cannot be larger than length of string. (Parameter 'startIndex')
at System.String.ThrowSubstringArgumentOutOfRange(Int32 startIndex, Int32 length)
at System.String.Substring(Int32 startIndex, Int32 length)
I would appreciate any guidance on this matter.
Thank you for your support!
Hi @rhessinger,
Our Nexus docker repository is configured to use specific port (e.g. port 8080), but this port is not exposed externally. Here's an example response returned by the Nexus endpoint:
{
"name" : "example",
"url" : "https://nexus-example/repository/example",
"online" : true,
...
"docker" : {
"v1Enabled" : false,
"forceBasicAuth" : true,
"httpPort" : 8080,
"httpsPort" : null,
"subdomain" : null
},
...
"format" : "docker",
"type" : "hosted"
}
Instead, we have a proxy server that maps a custom URL (e.g., https://nexus-docker/) to the internal Nexus port.
All Docker operations (push/pull) work correctly through this custom URL.
Could this proxy-based URL mapping affect the Docker migration feature, or is there a way to specify the external (proxy) URL for migration?
Thanks.