Just to highlight, the standard/native Azure Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.
Local directory access (d:\local\Temp)-Every Azure Web App has a local directory which is temporary and is deleted when the app is no longer running on the VM. This directory is a place to store temporary data for the application. The sandbox implements a dynamic symbolic link which maps d:\local to point to this directory. The application naturally has read/write access to this directory.
The persisted files - They are rooted in d:\home, which can also be found using the %HOME% environment variable. For App Service on Linux and Web app for Containers, persistent storage is rooted in /home.
Symbolic link creation: While sandboxed applications can follow/open existing symbolic links, they cannot create symbolic links (or any other reparse point) anywhere.
You may confirm to see if the write is happening on the allowed path as mentioned above. At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. The target slot remains online while the source slot is being prepared and warmed up, regardless of where the swap succeeds or fails. To swap a staging slot with the production slot, make sure that the production slot is always the target slot. This way, the swap operation doesn't affect your production app.
Based on your requirement, you could also use a custom container in App Service that lets you make OS changes that your app needs, so it's easy to migrate on-premises app that requires custom OS and software configuration. See sandbox page.
Checkout these document for more details on this topic:
Run a custom Linux container in Azure App Service
Run a custom Windows container in Azure (Preview)
