Windows - can't use network mounted drives

Support
1

Hi, Syncing from a Windows Server. Syncthing was working fine when synced folder was D:\XXX\YYY. (D: is a local drive).

However, we moved “XXX” to a network drive, and now it is mounted under \some-path. Whatever I do - trying to use a folder on the net drive is failing.

  • Tried giving the drive a letter (using net use) - “T:”
  • Tried giving the drive a letter (using subst) - “T:”
  • Tried using symlinks to a folder in D:
  • Tried using
  • Tried using junction

All produced the same result - Syncthing attempts to create the folder, as if it doesn’t exist and fails. The error is even weirder as it looks like

Failed to create folder root directory mkdir \\?\T:\XXX: The system cannot find the path specified.

Any way to work around it?

2

What user account is Syncthing running under? Windows hides mapped network drives from other users, so make sure it’s the same user you are logging in with.

3

It’s running as a service. It was running as the default service user, and I even tried creating a new user, add them to local admins and use that for the service to run. still same.

4

The user who the service runs under will need to be the same user who mounts the network share.

Windows blocks other users from accessing network shares that have been mapped by other users (even admins).

5

Ok - Tried using that user (not local - AD user) for the service - the service runs fine, still can’t add folder from the net drive.

The weird part is that it tries a very weird path for mkdir:

2023-05-10 13:47:48: Failed to create folder root directory mkdir \\?\T:\XXX ... The system cannot find the path specified.

(“XXX” is the root - one folder above what I’m trying to add)

6

Now I even followed this:

still - service can’t see the drive (or can see - but behaves weird re the paths)

7

Is AD just being used for password authentication?

Actually the path above is perfectly normal…

Most users see UNC (Universal Naming Convention) paths written like so:

\\server\folder\file

or

\\C:\folder\file

But in reality that’s the shorthand version. There’s also a longhand version:

\\?\C:\folder\file

Assuming that “XXX” exists, the problem is that “T:” doesn’t exist for the user Syncthing is running under.

8

@uris

Can you run Syncthing on that other server and use it that way? This way the second/new server you moved the files to can handle syncing files by itself.

1 Like
9

It is sub-optimal to configure a service to run from a user’s account, there are a number of potential problems and it’s fragile (for example, a user changing their password silently breaks the service).

If Syncthing is running under localsystem then you need to grant permissions (to the Share and at the NTFS level) on the server to the computername$ of the machine where Syncthing is running. If Syncthing is running as a separate user account then grant permissions to that account.

Regardless do not use mapped drive letters, use the full unc path in the form \\servername.domain\sharename\foldername, mapped drive letters not only exist only for an individual user (keep in mind you can have multiple users logged in to a computer at once, they each have their own set of mapped drives) but if the network isn’t available on login a mapped drive doesn’t get created, and there are cases where they get completely forgotten.

10

There’s no “other” server. it’s a network volume (AWS) mounted on few Windows machines (I’m trying to sync from one of them to a different, remote Ubuntu)

11

Agree re the security degradation - but I’m grasping at straws. I was hoping to get something working and dial security from there.

OK - now it’s working, and the full set was:

  • use the full UNC path (thanks @thedaveCA )
  • run the service in a real user (the one mounting the path). not ideal, but will have to do for now.

Thanks all for stepping in and helping!

2 Likes
12

Awesome!

13

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