I am on an enterprise version of Studio 23.10 and wanted to upgrade to Studio 2024, however there were issues with opening files from shared drives. I logged a ticket with UiPath support who confirmed it was a bug and that it is likely to be resolved in version 2025. Fast forward to a year later and I download the new LTS version 2025 and none of my shared drive projects open from the shared drive. I keep getting an error 'Studio closed the active project due to a critical internal error. You may retry to open the project". One time a project opened on the third try, but I got the same error when I tried to run it.
I copy them to local C and they work fine. All the while Studio 2023.10 works fine with any project location.
I raised a ticket with UiPath support and the below was the official response:
"I understand that you are encountering issues with opening and running projects located on a shared drive in the new LTS version of Studio 2025.10.1, and that this issue was also present in Studio 2024. I can see how this would be frustrating, especially since you are considering upgrading from Studio 2023.10, where these issues were not present. I appreciate you providing detailed information about the scenarios and the error message you are encountering.
We had similar issues in the past, after discussing with our Product Team, I wanted to share some insight. While projects on shared drives may have worked in Studio 2023.10, it wasnât part of the intended design due to security risks. Storing projects on shared drives poses challenges, such as limited control over project files, which can become a concern from a security perspective. The Product Team is actively exploring the possibility of officially introducing this functionality in future releases, though at the moment itâs still in the planning stages without a confirmed timeline.
In the meantime, to ensure a smoother experience with the latest Studio version, we recommend using version control tools like GIT or opting for a local repository to manage and store your projects."
Have I missed something? Have there been any deprecation notices? Opening projects from shared drives have always been available ever since I started with Studio v 2016. I understand the version control is the way to go, but not everyone has access to it, and it doesnât seem right that UiPath mandating what the customers should use. The official documentation still says projects can be stored on shared locations Studio - Project Organization
Itâs better to store the project on local drive instead of shared drive because the Studio generates & uses lots of temporary files while we work on any code. Due to latency of the shared drive, the studio faces this kind of issues.
Thank you for your reply - I guess the question for me is not whatâs better, local drives arenât a solution if thereâs a team that needs to constantly copy the project to and from local/shared. Also the official documentation states that shared drives are supported.
Genuinely interested - are there material differences between Studio 2023 and Studio 2024/2025 so that the later versions cannot work with the same projects on the same shared drives with the same shared drive speed, whereas there are no issues on version 2023?
I dont think this counts as a deprecated feature as it was never offically supported that they would work from shared drives, but instead was a happy accident for you that they did.
Its also an unhappy accident that they no longer do.
As such this is unfortunate for you, but you shouldnt expect a deprecation notice for such a thing. They cannot except every scenario and cover things that âmight workâ but arenât the intended use.
You are left with the reality of needing to use version control, which is a really important tool and something Iâd refuse to work without, and at least with GIT you do need that to be local.
You mention not everyone has it, Iâd be curious to know whats stopping you from adopting it? Its available on alot of platforms etc, you might not have it YET, but I am not sure what would be stopping you getting it. You arenât going to get anywhere insisting that shared drive support should be âfixedâ so Iâd suggest in investing in alternatives.
⢠Shared drive project hosting was never officially supported, even though it happened to work in older versions (like 2023.10).
⢠Starting with UiPath Studio 2024 and continuing into 2025 LTS, the way the Studio handles file access, project locking, and security has changed.
These changes enforce tighter security policies and more strict project structure validation, which can break compatibility with shared network drives.
⢠The internal âcritical internal errorâ youâre seeing is not a bug per se but a side effect of unsupported storage behavior â essentially, Studio fails to handle the file system latency or permissions on network shares the same way as local or Git-managed projects.
Thank you for your input - I do agree with you on the importance of the version control, it is a best practice and a way forward, and definitely a not yet for me However I also think different organisations work in different technical contexts and what suits one may not always be feasible for another.
Having said that, as a paying customer I would not like to rely on accidents in the product I pay for, especially if a feature is detailed in the official documentation.
While I understand that the shared drive functionality may not have been an official feature, it was consistently functional across multiple previous LTS releases for many years and therefore reasonably considered stable behaviour. If this behaviour has now changed, the responsible approach would be to provide some sort of explanation. I understand that changes happen, however I was told that it was a bug and would likely be resolved in v 2025. Even if it wonât be fixed, it is good to have a discussion around these topics and raise awareness.
Can you reference the official documentation where usage on the shared drive was stated as known and supported behaviour?
Cause otherwise, I have to express again, just cause it was able to handle it, doesnât mean it should be expected to moving forward when that was never the intended usage, regardless of the product being licenced or not. Functionality that exists outside of the intended and supported scope cannot be expected to be maintained.
I referenced this page when I was looking for information, and there are multiple references to the shared drive when storing custom activity packages, and under the âWhere to Store Reusable Componentsâ
But overall, it is based on my experience of using previous UiPath versions and the bug fix info related to the shared drive.
Could you suggest where I find more info on the intended and supported scope please, I would like to understand this better - to me trying to fix bugs for shared drive issues mean that the feature was in support. The version control documentation also states itâs the recommended route for project management, and I understand that itâs best practice, but until now UiPath wasnât enforcing it and ruling out storing projects on shared drives altogether.
I am happy with the previous reply by UiPath where they confirm it was never officially supported, it was my misunderstanding based on the experience that itâs always been working.
This line I think needs to be removed. Thats absolutely not best practice, the workflows should be added to a library and shared via the library.
I see why you are annoyed by this given stuff like that is about. I hope they change this documentation.
Common (reusable) components (such as App Navigation, Log In, Initialization) are better stored and maintained separately, on network shared drives. From that drive, they can be invoked by different Robots, from different processes. The biggest advantage of this approach is that any change made in the master component is reflected instantly in all the processes that use it.
However I also think different organisations work in different technical contexts and what suits one may not always be feasible for another.