For now we try to use a workaround - It would be really helpful for us if this would be implemented into the code in the future.

So I succeeded this time, I changed the montpoint to /data and created the subdirectories: mkdir -p /data/proget/proget-backups mkdir -p /data/proget/proget-database mkdir -p /data/proget/proget-packages Set correct permissions on the folders (same permissions as on the./proget-* folders) chmod 700 /data/proget/proget-database/ chmod 755 /data/proget/proget-backups/ chmod 755 /data/proget/proget-packages/ Set ownership chown 101:root /data/proget/proget-database/ chown root:root /data/proget/proget-backups/ chown root:root /data/proget/proget-packages/ Set correct SELinux context semanage fcontext -a -t svirt_sandbox_file_t "/data/proget(/.*)?" restorecon -Rv /data/proget Stop- and remove proget (I had a sapshot of the server as backup) docker stop proget docker rm proget rsync data to new directory rsync -avh ./proget-packages/ /data/proget/proget-packages/ rsync -avh ./proget-database/ /data/proget/proget-database/ rsync -avh ./proget-backups/ /data/proget/proget-backups/ Then install with (:z added for SELInux) docker run -d --name=proget --restart=unless-stopped \ -v /data/proget/proget-packages:/var/proget/packages:z \ -v /data/proget/proget-database:/var/proget/database:z \ -v /data/proget/proget-backups:/var/proget/backups:z \ -p 8624:80 \ proget.inedo.com/productimages/inedo/proget:25.0.18 last, remove the old directories in root home folder after ensuring everything is OK. cd ~ rm -rf ./proget-packages ./proget-database ./proget-backups Now it works as expected. i don't know what I did wrong last time, but now proget isn't filling up the root directory anymore. probably obvious for everyone used to docker, but wasn't for me :)

Hey Alana, No worries. I have a similar issue with an Ansible deployment in Kubernetes with permissions. So I have a special file share now for images that don't support changing the user/group that processes run as. Basically, the file share exposed and consumed by the image is configured (when using squashing) to have certain permissions. And we can make docker containers or Kubernetes deployments compatible by specifying the securityContext to tell it when user & group to run the pod as, or some containers allow specifying a user ID and group ID as environment variables. This is just to control the linux permissions for folder/file access. Somewhere in the image setup, there's configuration forcing it to access /var/proget/database as the user "postgres" and with the group "root", and it tries changing permissions on that folder at some point. If the image supported the securityContext or the user/group ID environment variables, it would run as those specified permissions instead - but - your image would need to be able to run as those permissions, and it would probably take some work to get the image reconfigured to allow that, and to do testing. For now, it works. It would take some evaluation to see if your image would support changing the user/group away from the current postgres/root.

Yes , it is indeed npm packages, yes I was using /packages. Though when traying to search within /feed it was also strange as it seems to ignore @ . Both are okay for now. Just put it somewhere in the improvement list, I understand there is some limitation to it, encoding, filter etc and trying to do universal search across different type.

Hi @jw , We added "auto-publish Inedo.ProGet" to our internal tracking list -- and in theory it will be done in the next week or so. I think we meant to do that earlier but it just fell off the list. Thanks for pointing that out - please don't hesitate to bug us if you don't see it published next time :) Thanks, Alana

Hi @jolaka9284_9459, We have pushed some improvements in ProGet 2025.18. These improvements include: Improved connector metadata caching (may require an increase in the number of cached requests) Improved index generation code A new Feed management setting for Dependency Resolution Standard Resolution, check in ProGet if that dependency exists Force all dependencies through ProGet Always use this feed unless Registry is specified In your case, since you are using ProGet as the mirror, I would suggest forcing all dependencies through ProGet, which can be configured on Feed -> Manage Feed. Thanks, Rich

Hi @wechselberg-nisboerge_3629, In ProGet, the maven metadata files (xml, hash) are indeed generated upon request. The output is deterministic, based on the artifacts in storage and (if relevant) in the remote repository (i.e. connectors). So, if you're seeing it changed, it's because an artifact was uploaded/etc. One thing to note -- you cannot upload a metadata file or hash file. Well, you can try (and maven tries) to PUT the file, but the stream is always ignored or "written to /dev/null" as they say. We've seen some maven workflows/plugins that attempt to modify/append to this metadata file and re-upload it with changes. Thanks, Alana

Hi @atripp, thanks for the explanation. I can understand that you are not willing/able to change this behavior. Now I will check if it is possible for us to modify the underlying wget call to allow downloading of the files from ProGet. Best regards

Thank you

@rhessinger While that kind of makes sense, I dont think that is the issue. In the past, I've imported projects from production TC servers to the test server. Thinking this may have been part of the problem, I instead created a brand new project on the test server called "WebProjects_SessionManagement". After creating the project, I created the build config "WebProjects_SessionManagement_BuildChanges". I created 3 dummy steps and then ran those builds 3 times. After that was done, I created a new Application in BuildMaster. When I went to import the 3 builds I created, it resulted in the same behavior that I saw before. When I check the API (/app/rest/projects/WebProjects_SessionManagement?fields=buildTypes(buildType)), I get this for projects: <project> <buildTypes> <buildType id="WebProjects_SessionManagement_BuildChanges" name="BuildChanges" projectName="Web Projects / Session Management" projectId="WebProjects_SessionManagement" href="/app/rest/buildTypes/id:WebProjects_SessionManagement_BuildChanges" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges?mode=builds"/> </buildTypes> </project> And then when I check the builds for this project (/app/rest/builds?locator=defaultFilter:false,project:WebProjects_SessionManagement&fields=build(id,number,status,state,webUrl,startDate,buildTypeId)), I get this: <builds> <build id="10342" buildTypeId="WebProjects_SessionManagement_BuildChanges" number="26.20.0117.3" status="SUCCESS" state="finished" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges/10342"> <startDate>20260117T214753-0500</startDate> </build> <build id="10341" buildTypeId="WebProjects_SessionManagement_BuildChanges" number="25.20.1317.2" status="SUCCESS" state="finished" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges/10341"> <startDate>20260117T214729-0500</startDate> </build> <build id="10340" buildTypeId="WebProjects_SessionManagement_BuildChanges" number="25.20.1317.1" status="SUCCESS" state="finished" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges/10340"> <startDate>20260117T214719-0500</startDate> </build> </builds> and yet, no builds in the dropdown in BuildMaster

Hi @koksime-yap_5909, No problem! Happy to help! Thanks, Rich

Hi @Julian-huebner_9077, This error is occurring while ProGet is trying to generate the "base url". There are a few inputs that go into this: Admin > Advanced Settings > Base URL X-Forwarded Headers, set by a reverse proxy like ngnix If any of those have an invalid host name (which is what the error is indicating), then you'll get this error. In most cases, it's a typo in the X-forwarded headers. Thanks, Alana

Hi @dwynn_6489 , I was able to reproduce this issue; the issue is that the package's license declaration specifies a license file of package/license.txt, but that file does not exist in the package. We will improve this error message via PG-3199 in the upcoming maintenance release, but in the meantime, the only workaround is to manually assign the license under SCA Licenses. The new version of ProGet will include a direct link to that page for convenience. The Purl you'd need to add is as follows: pkg:npm/%40progress/kendo-charts@2.9.0 Hope that helps, Alana

Hi @spencer-seebald_1146 , I was able to identify the issue. When you visit the URL in ProGet, then ProGet will visit this URL (slightly trimmed) with the appropriate authorization header: https://libraries.cgr.dev/javascript/..../lodash/-/lodash-4.17.20.tgz However, that URL will issue a 307 redirect to the following: /artifacts-downloads/javascript/namespaces/15f7d141c3b76b85/repositories/.../downloads/ABmYrfCH......KpxO1ducu3xmMRtw== ProGet then follows the redirect, but does not send the authorization header. And thus, a 401 is issued. This is actually the default/expected behavior in HttpClient (i.e. the library in .NET we use) and most clients in other languages (Java, Go, Ruby, etc.) as well. Of course it can be worked-around by disabling auto-redirect and implementing yourself to follow the URl with the same header. But that's not so common and, as such, it's not a common practice for servers to issue redirects that require authentication; we see other services handle the redirect using some kind of token in the querystring. On our end, this has not been an issue to date. This is logic is buried pretty deep and it's not an easy fix without changing code everything relies on. I'm kind of surprised npm and pip override the default behavior in the fetch() and requests libraries. Anyway, it sounds like you can make a change on the private repository server code... so I would here would be to just disable authentication on your artifacts-downloads endpoint. I mean that URL is basically authenticated anyway.... it's so long (I stripped like 1000 characters) that it's basically a password. Thanks, Alana

@atripp I'm sorry, you're absolutely right. It does indeed work with version 2025.18. I simply forgot to apply the license key with pgutil before attempting to create the API key. Then I confused myself more when 2024.39 wasn't throwing the same error (because I was still setting the license with the --LicenseKey Inedo Hub option). For anyone stumbling here in the future like me, here's what you need to do to apply the license key and create an API key with pgutil: pgutil sources add --name=Default --url=http://localhost:8624 pgutil settings set --name=Licensing.Key --value=LICENSE-KEY-GOES-HERE api_key=$(pgutil apikeys create system)

I noticed this mechanism when I migrated from Artifactory to Proget in my company but only able to comment now. I would say thank you very much for you guys for addressing this, especially since it is done before the migration in my company.

Hi @Sigve-opedal_6476, I just tested with a 3GB .iso file and could upload without issue. When you tested locally on the same workstation, did you use http://localhost or the normal URL? Chances are the normal URL will still go through the firewall, even when on the same workstation. I would check in with your IT team and see if they are blocking .iso upload files to your ProGet instance. Thanks, Dan

Hi @dafex36959_6595, Based on the exceptions, this is most likely due to an invalid character in the display name field or in an associated group. This is due to a bug that is buried in a third-party library that is based on another library that is based on an some RFC standard.... but who knows. It's been a known issue for years, and presumably end-users of this library (it's the #1 library for LDAP on .NET) have simply worked-around the issue by not using those characters in domains, groups, etc. I'm afraid it's just not something we are able to fix. We really hate giving this response, but we also cannot go down the rabbit hole of trying to fix the library to support this edge case -- Unfortunately, this is a "limitation" of our software and recommend working around the issue by either removing the unescapable character (typically a '# or a ',') or try using ADv4 and override the display name to use a different field and/or group discovery. Thanks, Dan

Hi @jonathan-werder_8656 , We actually don't have any Azure-specific recommendations (or Amazon, GCP, or any host really) -- so just the normal Windows or Linux (Docker) guidance would apply. Happy to clarify that in the docs if you can think of a good pace to put that :) Thanks, Alana

@atripp thx for the info.