SMB share Alias

I thought I might be able to create an alias for an smb share, such as this:

Remote or path to alias.
Can be “myremote:path/to/dir”, “myremote:bucket”, “myremote:” or “/local/path”.
Enter a string value. Press Enter for the default ("").
remote> \\AliasTest
Remote config

type = alias
remote = \\AliasTest

Subsequently rclone fails like this:

PS C:\WINDOWS\system32> rclone -vv copy smbAlias: g:
2018/09/18 15:11:07 DEBUG : rclone: Version “v1.43.1” starting with parameters [“C:\WINDOWS\system32\rclone.exe” “-vv” “copy” “smbAlias:” “g:”]
2018/09/18 15:11:07 DEBUG : Using config file from “C:\Users\wrh\.config\rclone\rclone.conf”
2018/09/18 15:11:07 ERROR : : error reading source directory: directory not found
2018/09/18 15:11:07 INFO : Local file system at \?\G:: Waiting for checks to finish
2018/09/18 15:11:07 INFO : Local file system at \?\G:: Waiting for transfers to finish
2018/09/18 15:11:07 ERROR : Attempt 1/3 failed with 1 errors

Maybe “Alias” isn’t meant to work that way. IDK…

Edit: somehow the leading slash gets dropped when the forum displays the message. “\192…” is actually “\192…”

Edit: did it again… lol…

Can you see if rclone lsf \\\AliasTest works OK?

If it does I think it might be something to do with \ and / translation…

Can you try using remote = // in the alias?

Put them in ` backquotes ` so \\192...

It does.

I tried that with the same failure. I’m running on Windows 10 if it matters.

The endgame for me would be that I could create a remote or alias where a network share was the type of storage and rclone would prompt for a username and password and store it as part of the remote.

I’ve discovered the problem with this - it is a bug in the alias backend processing the Windows paths incorrectly.

Try this: (uploaded in 15-30 mins)

I believe that has resolved the issue. I’ll continue to test in my systems.

Thank you for continuing to be personally involved in the development and maintenance of rclone. I have many instances that reliably do real work every day…

1 Like

I’ve merged that fix into the latest beta now and it will be in the 1.44 release.