Inconsistent 403 when client tries to access pulp rpm repo with Azure storage BE

[sbriand]

Problem:
When I do a dnf makecache or dnf update (on a machine that points to my pulp repo server) I sometimes get a 403 from the pulp repos as result:
$ sudo dnf makecache
AlmaLinux 9 - Extras 22 kB/s | 3.8 kB 00:00
Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 7.5 kB/s | 993 B 00:00
Microsoft Production 3.6 kB/s | 481 B 00:00
AlmaAppstream 9 - Pulp 3.1 kB/s | 489 B 00:00
Errors during downloading metadata for repository ‘AlmaAppstream’:

• Status code: 403 for pulp-contain/artifact/d8/02e917248346ab6f9bea1568105e2e90b50e9e7d75d759c83acc2116c49f4f?se=2025-06-13T16%3A47%3A13Z&sp=r&sv=2025-05-05&sr=b&rscc=no-cache&rscd=attachment%3Bfilename%3Drepomd.xml&rsct=text/xml&sig

Note: I removed the signature and the initial part of the address so it won’t link in the post

Expected outcome:
The dnf command completes without error.

Pulpcore version:
{
“component”: “core”,
“version”: “3.76.1”,
“package”: “pulpcore”,
“module”: “pulpcore.app”,
“domain_compatible”: true
},

Pulp plugins installed and their versions:
“versions”: {
“deb”: “3.5.2”,
“npm”: “0.3.3”,
“rpm”: “3.29.2”,
“core”: “3.76.1”,
“file”: “3.76.1”,
“maven”: “0.10.1”,
“ostree”: “2.4.8”,
“python”: “3.14.0”,
“ansible”: “0.25.0”,
“certguard”: “3.76.1”,
“container”: “2.25.0”

Operating system - distribution and version:
AlmaLinux 9.6

Other relevant data:

This command will eventually work if I give it a few minutes. The azure network security is setup correctly to allow it to access (it eventually works if the security wasn’t setup correctly it would never work)

I don’t have any issues when I sync my repos.

Here is my config for azure storage:
MEDIA_ROOT = “”
STORAGES = {
“default”: {
“BACKEND”: “storages.backends.azure_storage.AzureStorage”,
“OPTIONS”: {
“account_name”: ‘reskitscoreccpulpstore’,
“azure_container”: ‘pulp-contain’,
“account_key”: {{{ removed }}},
“expiration_secs”: 60,
“overwrite_files”: ‘True’,
“location”: ‘’
},
},
“staticfiles”: {
“BACKEND”: “storages.backends.azure_storage.AzureStorage”,
“OPTIONS”: {
“account_name”: ‘reskitscoreccpulpstore’,
“azure_container”: ‘pulp-contain-static’,
“account_key”: {{{ removed }}},
“expiration_secs”: 60,
“overwrite_files”: ‘True’,
“location”: ‘’
},
},
}

If someone has any experience here some advice would greatly appreciated!

Thanks,
-Sheldon

[sbriand]

It looks like my requests are being made with a SAS token that has already expired.

As an example:
–2025-06-25 09:01:00-- (this time is EST) but the se field in the request is se=2025-06-25T12%3A38%3A01Z

Both the pulp server and the client server requesting patches are synced with the same time server.

I have set my expiration seconds to 400 in my storage configuration. Maybe I need to set it to 3600?

[x9c4]

I think the “Z” in the datetime means UTC and EST is some hours behind. But still you seem to have like a 37 minutes (plus or minus an hour) difference here. 400 sec is less than 10 minutes. Sounds like something is caching the urls for a bit too long.

[sbriand]

I set the expiration to 3600 and that fixes my problem. This issue can be closed.