NetDrive3 mounted drives share-permissions drop-after-reboot

I refer to the NetDriv3 topic found in support history of Jul-2022

We encountered the same/similar problem with version 3.18.1125 … which still occurs after the provided command

sc config LanManServer depend= Samss/Srv/NetDrive3_Service_x64_NetDrive3

We are using the tool now after porting (and upgrading at the same time ) from a different machine with Win10 to a Win11_24H2.

The drives are configured to be added as Local drives when system starts but all Shares are showing state “Not Shared” and we need to re-share it to our needs.

Do you have a guess what happens here? We can’t anymore say which version was installed on the older Win10 machine ( very likely older the 3.17.366 – the initial setup on that computer was done in 2019 ) but for sure the shares was always persistent after a reboot.

Thanks for any hint - Jens ( on behalf of Kostas )

Dear Jens,

Here’s a clear and focused solution using only a startup script to resolve the issue where NetDrive-mounted drive share settings disappear after reboot on Windows 11 24H2.


Key Components

  1. Script example (e.g., restore_share.bat):
@echo off
:Retry
timeout /t 10 /nobreak >nul
if not exist X:\NUL goto Retry
net share MyShare="X:\SharedFolder" /GRANT:Everyone,READ
  • Waits 10 seconds repeatedly (timeout), checks if the drive is ready (if not exist X:\NUL), and once ready, runs the net share command to set the share with Everyone,READ permissions.
  1. Task Scheduler setup:
  • Trigger: set to “At logon” or “At system startup with delay (e.g., 60 seconds)”.
  • Run as: the current user or system account. If using system account (Local System), consider using a UNC path instead of a drive letter.

Why does this work?

  • NetDrive mounts are treated as fresh drives at each boot, so Windows doesn’t retain previous share settings automatically.
  • This script ensures the share is recreated each time after reboot, providing a reliable and consistent workaround

Please go ahead and test this setup. If the issue persists, just let us know—we’re ready to investigate further and provide additional support immediately.

Thank you for the solution proposed. The share prepared with the provided script is working - and it was persistent after at least two (testing) reboots.

One additional comment - which is perhaps related to the general share-approach with the ‘net share’ command: It was necessary to change the physical FTP-repository to provide a subfolder which can be addressed as “SharedFolder” behind the drive letter. If the base drive letter itself should be shared it was not possible to get a share.
Potentially this was the case as well in our first attempt - but I did not test this again - I stay with the script and the scheduled task.

Jens

Dear Jens,

I’m glad to hear that the script combined with Task Scheduler is working smoothly—and especially that the share remained persistent after two test reboots. That’s excellent news!

If you encounter any further issues, please don’t hesitate to let me know. I’m here to assist with additional checks or refinements if needed.

Once again, congratulations on successfully resolving the issue and wishing you trouble-free, stable operation ahead!

Thank you.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.