- Azure Explorer is uploading too slow
- AZCopy copy feature will not upload. Error: “RESPONSE Status: 403 This request is not authorized to perform this operation using this permission.”
Today, I was trying to upload a directory (1.3gb) of images up for blob storage for public access. Though I often use Azure Storage Explorer for smaller uploads, it was proving impossible with this large directory. My connection came to a grinding halt and the files where taking impossibly too long to upload.
So, upon research, I learned that AZCopy is much more efficient with larger data transfers and after success, I found this to be true. However, using a direct URL as per the docs was giving me a 403 error, despite me being owner of container and container seeming to have proper permissions. So I decided to use an SAS key at end of URL (also in docs) and the apply the azcopy copy command.
Below is how I proceeded to get it working.
The idea behind this was to create a nice, easy UI that users can download media files they request often. We moved it to Azure to prevent killing our on-prem bandwidth, but then I had to deal with the flat file structure, etc. The end result was simply: a fast search of all the blobs (with link) and underneath that, a tree structure of the blobs that they can browse through.
The Set Up
First, I created a Storage container through Azure Portal, then I used Azure Storage Explorer to create a Blob Container under that storage account. I also set read-only permissions to my blobs by right clicking the container in Azure Storage Explorer, then: Set Container Public Access Level > Public Read Access for Blobs Only.
To make this code work, I needed to setup an environment variable for my connection string. I used the prefix CUSTOMCONNSTR_ on my variable name as it comes in handy when deploying to Azure Web Apps. To get the connection string: Azure Portal > Storage Account you created > Access Keys.
setx CUSTOMCONNSTR_storageConnectionString "<yourconnectionstring>"
Finally, I got a folder I wanted to share and dragged and dropped it into my …
I recently had an issue with printing a report to PDF using Microsoft Reporting Service and a RDLC file, etc. Something similar to this. Unfortunately, it worked great in development, but refused to work once deployed into Azure. No matter what I did, I could not duck the GDI errors I kept getting, and apparently this continues through a line of various PDF exporting extensions, all of which rely on GDI for export. Turns out, I’m not alone in facing this problem and so, I decided to find a solution.
My general idea was to use something to render my PDF view, send that view as one long html string to a free PDF microservice and get the PDF in return.…
This week I had to address a upload image to blob application that I had built in my development environment, was working fine, but needed to be configured to work in production. For the application overall, I used Azure Samples for Upload Image to Storage (built in .NET Core). In it, the configuration in appsettings.json looks like this:
Account Name account name and AccountKey are easily found in Azure Portal, for container I used Azure Storage Explorer just so I could get a full look at the container and its blobs. The problem was, in my development environment I was uploading DIRECTLY to container. In the example above, I was uploading to the “images” container. In my Production environment, though, my ImagesContainer had two folders: images/small and images/large. I tried to change the “ImagesContainer”:”images” to “ImagesContainer”:”images/small”, “ImagesContainer”:”images\small” and no go. Requested URI not found.…