Help deleting 'folder' in SPO?

Occasional Contributor

We've gotten a into a strange situation with a modern SharePoint Online site and could use some help/ideas on how to get out of it:


A file was deployed with the Feature framework style of deployment to a path of /SiteAssets/myfile.ext. However, this happened prior to the Site Assets library actually being created by the 'just-in-time' model used on modern sites.


As a result, the site now has a root 'folder' named SiteAssets and it is blocking the JIT creation of Site Assets library. When I say 'folder' think web/IIS folder, NOT a SharePoint folder in a library.


How would one delete this kind of 'folder' such that the Site Assets library can actually be created? I've tried various forms of SPO/PnP PowerShell and none of the cmdlets seem to work with this kind of 'folder' :(


Any help/ideas would be MUCH appreciated...



4 Replies
best response confirmed by Jim Duncan (Occasional Contributor)
You should be able to see the folder if you check the content from Web.RootFolder objective. So connecting to web level and then access the RootFolder property from there.

Thanks, Vesa.


I am indeed able to see the folder but unable to delete it. Even as Site Collection Administrator, I receive access denied using CSOM in PowerShell.


The customer has chosen to delete the site and start over, so it is no longer an issue at this point. EDIT: The customer has found another site with this issue and doesn't want to start over with that one because too much other work has already been done on the site.


I wonder how much time is really being saved by skipping the creation of Site Assets during site creation and if it is really worth it. It can't take much longer than creating the Style Library and Form Templates, which we don't even really use anymore...

@Vesa Juvonen 


Had a face-palm moment: I simply had to enable scripting on the site and then I was able to rename the folder. With that done, Site Assets was able to provision itself on-demand.


I'm not as think as I smart I am ;)



Interesting that it's a requirement for that, but thanks for sharing. Good for others to know if they will run into this scenario.

SharePoint works in mysterious ways - it's not about being smart by knowing, rather being smart on testing different options - which you did.