Skip to content

Share workspace directory to remote Windows machine

Micah Young edited this page Oct 20, 2020 · 2 revisions

Requirements

  • MacOS workstation
  • Windows 10 or Server 2019 machine where source needs to be executed/built/etc
  • Network access between machine
    • LAN/VPN/WAN all are secure over SSH

Option 1: Git push to Windows machine as remote

These goal of this option is to allow this workflow:

  • Workstation

    # <edit code>
    git commit --all --message "Work in progress"
    git push windowsdevbox
  • Windows machine

    git reset --hard HEAD
    make  # <or other command>

This setup is simple and good for slow connections. It requires repeated steps every time you want to sync but makes building/running commands as fast as possible.

On Windows machine

  • Clone your repo/branch to initialize
    git clone --branch <branch> --config receive.denyCurrentBranch=warn https://github.com/buildpacks/pack c:\Users\<windows user>\workspace\pack

On Workstation

  • First time, add a git remote and push

    git remote add windowsdevbox <windows user>@35.236.212.142:c:\\Users\\<windows user>\\workspace\\pack
    
    git push windowsdevbox
  • For every change, make a WIP commit and push. This automatically updates the current branch on the remote so you are ready to build/run

    git commit --all --message "WIP"  
    
    git push windowsdevbox
    

On Windows machine

  • Reset your branch to latest pushed commits
    git reset --hard HEAD  
    

Option 2: SMB over SSH

These goal of this option is to allow this workflow:

  • Workstation

    # <edit code>
  • Windows machine

    make  # <or other command>

These instructions walk through securely exposing a local directory to a remote windows machine as a SMB shared drive over an SSH tunnel.

It works by running the built-in MacOS SMB server to share your directory, SSHing into the remote machine, port-forwarding connections between the local and remote machines, then creating a normal SMB Mapping on the remote Windows machine. The setup is more complex and works best over fast internet connections.

On Workstation

First, create a new dedicated user for sharing your files. This user should have a secure but easy-to-type password as you'll need to enter a few times. This account will have minimal privileges to access only the files you intend to share.

  • Create a new user for sharing

    • System Preferences -> Sharing -> Users & Groups:
      • Click on the 🔒 and authenticate
      • Click + and in the modal:
        • Change New Account: to Sharing Only
        • Chose a meaningful Account Name: (e.g share)
        • Click Create User
  • Create a SMB share for ~/workspace directory

    • System Preferences -> Sharing -> File Sharing:
      • Toggle File Sharing to On
      • Click + and add /Users/<your workstation user>/workspace
      • In Shared Folders:, click workspace
      • In Users: list:
        • Click + and add your share-user (if not already present)
        • Change your share-user to Read & Write
        • Change Everyone to No Access
      • Click Options... and in the modal:
        • Toggle Share Files and folders using SMB to On (if not already)
        • Toggle your share-user to On (enter new share-user password to confirm)
        • Click Done

On Windows Machine

This enables the Windows VM to "map" your workstation's shared folder as a Windows drive (i.e. w:\)

  • Allow port-fowarded localhost SMB mappings

    netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=445 connectaddress=127.0.0.1 connectport=50445
    Stop-Service lanmanserver -Force
    Set-Service lanmanserver -StartupType disabled
    
    #Windows 10 only:
    Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\com.docker.service DependOnService -Value @()
  • Restart computer to apply service changes

    shutdown -r -t 0
  • SSH to your Windows machine and remote port forward back to your workstation

    ssh <windows machine user>@<windows machine ip>  -R 50445:localhost:445
  • In the SSH Session, mount your port-forwarded SMB drive using your share-user credentials

    New-SmbGlobalMapping `
      -RemotePath \\localhost\workspace `
      -LocalPath w: `
      -Credential (New-Object -TypeName PSCredential -ArgumentList @((Read-Host "Username"),(Read-Host "Password" -AsSecureString)))
    
    # Username: <workstation hostname>\<share-user username>  ## Ex `laptop\share`
    # Password: **************** 
    
    cd w:\
    • Note: Your Username must be prefixed with your workstation hostname (lookup with: hostname -s)
  • Important notes:

    • Your workstation's SMB credentials are cached on the windows machine for as long and the drive is mapped. If your SSH session ends, the drive will try to reconnect automatically using saved credentials when you reconnect again
    • Remove drive mappings with Get-SmbGlobalMapping | Remove-SmbGlobalMapping -Force
    • Connections are bi-directional - the Windows VM can change anything that your SMB user has permissions for in your workspace directory, including deletion. Adjust folder permissions or mount specific sub-directories if possible.
    • Newly created files from the Windows machine will be owned by the share-user on your workstation. You may need to sudo chown -R <workstation user> <files> or git clean/checkout to fix ownership problems.
  • Leave SSH session running and run commands

  • Make changes on workstation or Windows machine and see them synced

Troubleshooting:

  • Error: New-SmbGlobalMapping : The specified network name is no longer available.
    • Be sure -R 50445:localhost:445 is on the ssh command line.
    • Run netstat -abn | findstr ":445" on Windows machine. You should see a single entry for 127.0.0.1:445.
    • Run ssh with -v during New-SmbGlobalMapping command. You should see a ssh debug message during the attempted connection.
  • Error: New-SmbGlobalMapping : The semaphore timeout period has expired.
    • Disconnect and reconnect ssh
    • Disable and Re-enable MacOS filesharing in System Preferences
  • SSH+SMB over an additional VPN causes very poor performance. This appears unavoidable.