Hi @misael-esperanzate_5668 , I'm not really sure, but I'll explain how things work so it might help troubleshoot. First, the Maven API does not provide a file listing. While you (as a user) can often "see" via an HTML page (like this listing at jboss.org), it's simply not available for listing in the API. The only required file in an artifact is the .pom file, so when you "pull" an artifact to ProGet, that's all you'll get. Next, the "remote" icons next to the files indicate that they were cached (i.e. added to the feed) via a connector. That means the files were successfully written to disk, recorded in the database... but now they are gone. Hence, why you keep getting the "file not found" message. The most likely culprit for this is something deleting the files from a packagestore. We often see security tools doing that for "safety" reasons, since they are .jar files that may be dangerous I guess. Overall, the maven API is a very simple series of GETs. So perhaps, you can just experiment with this? First, start with a brand new feed and a connector. Then, run the command:; curl http://my.server.local:8624/maven2/my-new-feed/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar --output hamcrest-core-1.3.jar You should see the file download via CURL. Afterwards, you should see the artifact as a cached package (Top Navigation > Packages > Select Cached). You should also see that .jar file on disk, written to the package store location (Manage Feed > Storage). If you don't see a .jar file downloaded to that location on disk, then it means something is "blocking" the file being written. If it's there, then it means something is deleting it after. Thanks, Alana

To share with the community some things learned from a private support ticket -- There's currently a defect in the logic where if no packages were downloaded/uploaded to a debian type feed, the in-memory cache is never started. This leads to very long runtimes when running apt update since the response times for the /Release and /InRelease endpoints (from our experience) are at best 1 minute, at worst 10 minutes. The workaround support gave was to manually download a package via http before attempting to use apt. From our experience, this doesn't persist overnight, so it would basically need done daily and truly is counterintuitive to having a package manager like apt.

Hi @dean-houston Thank you for the ultra-quick response. Disabling that feature did indeed provide a workaround solution and currently testing is back on track. Thanks again Darren

Hi @layfield_8963, Looks like this was just a simple bug preventing output from being written when stdout has been redirected. It's now fixed in pgutil 2.1.1. Thanks for the update! -Greg

Hi @rel_0477, Thanks for sending over the reproduction case. I was able to identify the issue, PG-2993, and have it ready to go in the next maintenance release of ProGet. Thanks, Rich

Your response gave me a hint -- i was just missing the relevant environmental variables from the OCI image. This is now resolved, thanks!

@michal-roszak_0767 sorry, this is definitely sub-optimal and needs work Basically, when you have API Key Hashing available, there's no way for the page to filter the incoming requests. So, all of the items are shown. It's not really a trivial to fix and requires us to rethink a bit how we are storing/logging this data. We can explore revisiting as part of ProGet 2026.

@dimas said in Incomplete proget debian connector local index file for ubuntu noble-backports dist: why does the proget connector omit empty repository components altogether, instead of making them empty like virtually every other Debian repo? Most other Debian repos use or fork Dpkg to generate the folder structure based on files on disk. ProGet doesn't. Instead, we parse/index all packages in the repository in a local sqllite3 database. That database has a "Packages" table, and we use that to generate feed indexes (Release, InRelease). It's possible to change, and involves modifying the sqllite3 databases to add a Components table, and then changing the way we generate all the indexes. It's not too hard but it's not trivial and probably isn't worth it unless we get more feedback on the matter. Thanks, Alex

Hi @dimas , It looks like VSCode still doesn't support private galleries. I know users have been requesting it for over eight years now.... so maybe it'll come soon! But until then, we can't implement it in ProGet. I'm not sure what you mean about the python extension... but I do know that a visx file uses some kind of GUID to uniquely identify an extension. If the different "versions" of python visx use that same ID/Version, then I suppose it would get overwritten. Alex

@steviecoaster the Native API should provide access to all of those procs FYI

Hi @caterina, Thanks for bringing this to our attention. I have created a ticket, PG-2990, to track the fix and it should be released in the next maintenance release on June 13th. Thanks, Rich

Hi @steviecoaster, Thanks for the find. We'll get this fixed in the next maintenance release. Thanks, Rich

Hi @sgardj_2482 , ProGet's Integrated Web Server already supports Windows Integrated Authentication (WIA). Actually it supports WIA better than better than IIS in that only the Web UI and supported feeds (or ones you configure) will do the WIA challenge. Behind the scenes, the Integrated Web Server (IWS) uses Kestrel unless you're doing so-called "port sharing", which would be having two web applications sharing the same port. That's becoming less and less common, and isn't something Microsoft recommends anymore. If you bind to a host name in IWS (i.e. port sharing), then the operating-system level HTTP.SYS component is used. That is much less flexible with WIA and every request must be authenticated. Which means it'll never work with Docker, npm, etc. So it's not recommended. Thanks, Alana

Hi @michal-roszak_0767, Can you please post what the fix was? Thanks, Rich

Hi @michal-roszak_0767 , 401/403 are not logged, so you won't see a server side event. 403 means authentication was successful but the permissions are not OK My guess is that the wrong feed or credentials are being specified. Like maybe using an API key? Thanks, Alana

Hi Fritz, We appreciate the feedback on this! ProGet 2025 will indeed have a separate dedicated mount for the database, but we didn't include this in the preview. As to the other issues, yes we do have a supervisor that attempts to start postgres and perform a clean shutdown on container stop... but there are some bugs we are working through, likely made worse by the ownership issues you discovered. These concerns will absolutely be addressed before launch. Again, thanks for trying it out and please let us know of any other issues you find or suggestions you may have! -Greg

Thank you. Your comments clarified a few things. I added useApiV3 = $True to the body above, and removed the incorrect use of endpointUrl. The big mistake in the above was Register-PSRepository - I needed to update Microsoft.PowerShell.PSResourceGet to the latest version, and use Register-PSResourceRepository -Name $feed.ShortName -Uri $endpointUrl -ApiVersion 'V3' -Trusted -passthru, where endpointUrl was http://<hostname>:50000/nuget/$feed.ShortName/ Problem solved, thanks again!

Late reply (was out at a conference), but this was in fact permissions related. I've added a check to ensure the Inedo service account has been granted modify permissions on the drop path upon creation, and it is working appropriately!

Hi @parthu-reddy , This looks more related to Server Overload / Database than anything to me. Note how all the requests are coming in at exact same second. Can you throttle your load balancer a bit, so they don't all hit at the same time? Even a slight delay will help. FYI - we are tracking a recent regression to SQL Server analysis engine (???) that is causing one particular query (NuGet_GetPackage) to go incredibly slow under extreme traffic. For some reason, it's using the wrong plan suddly. It's been happening to a few users after a recent upgrade/patch to SQL Server. We have a work-around but would like to test it in the field against a user. Thanks, Alana

Hi @marc-ledent_9164 , This is available in InedoCore-3.0.4, so if you go to Admin > Extensions, you should be bale to update. thanks, Alana