Skip to main content
IMHCloud Logo
Back to support home

How to Set Up a Shared Drive in the Cloud and Connect from Windows

Set up a Samba file server on an InMotion Cloud Ubuntu instance and connect to it from Windows as a mapped network drive (like F:). Covers instance setup, security group rules, Samba configuration, the Windows drive-mapping flow, and troubleshooting.

9 min read
StorageTutorials

A shared drive in the cloud gives a team a single, central place to store and edit project files — CAD drawings, BIM models, marketing assets, design documents — without each person keeping their own copy on a local laptop. On Windows, the cleanest way to consume that shared storage is by mapping it as a network drive (the familiar F: or Z: drive in File Explorer).

This guide walks through the full setup on InMotion Cloud: provisioning a small Ubuntu instance, installing and configuring Samba (the standard SMB file-sharing service for Linux), opening the right ports in your security group, and mounting the share from a Windows workstation as a persistent mapped drive. Both the OpenStack Horizon dashboard and the OpenStack CLI are covered.

Architecture Overview

The shared drive is hosted by an Ubuntu instance running Samba. Samba speaks the SMB protocol natively, which is the same protocol Windows uses for its built-in file sharing. From the Windows client's perspective, the cloud-hosted share looks identical to a share on an on-premises Windows file server.

The major pieces:

  • Ubuntu instance — A small Ubuntu 24.04 LTS instance (2 vCPU, 4 GB memory, 20 GB root disk is enough for most teams).
  • Cinder volume — A separate block-storage volume attached to the instance and mounted at /shared. Keeping team data on its own volume means you can resize it independently, snapshot it, and reattach it to a replacement instance without copying terabytes of files.
  • Security group — A firewall rule that allows TCP 445 (SMB) only from the IP addresses your team uses (office IPs, VPN IPs). Do not open 445 to the public internet.
  • Floating IP — A public IP attached to the instance so Windows clients can reach it.

Prerequisites

Before starting, you should have:

Step 1: Launch the Ubuntu Instance

The Samba server itself runs on a standard Linux instance. Start by provisioning one in Horizon, then follow up with the CLI equivalent if you prefer scripted infrastructure.

Using Horizon

Navigate to Project > Compute > Instances and click Launch Instance.

In the Launch Instance dialog:

  1. Details — Name the instance (for example, fileserver-01) and set the count to 1.
  2. Source — Choose Image as the boot source, allocate the Ubuntu 24.04 LTS image, and select Yes for "Create New Volume" with a size of 20 GB. This makes the root disk a Cinder volume (good for snapshots and rebuilds).
  3. Flavor — Allocate a flavor with at least 2 vCPU and 4 GB memory. A smaller flavor works for light use, but file-server workloads benefit from headroom.
  4. Networks — Allocate the private network you set up in the prerequisites.
  5. Security Groups — For now, allocate the default security group. We will create a dedicated fileserver security group in Step 2.
  6. Key Pair — Allocate the SSH keypair you imported.

Click Launch Instance. The instance status moves through Spawning, Build, and finally Active.

Once the instance is active, attach a floating IP so Windows clients can reach it:

  1. From the instance's action menu, choose Associate Floating IP.
  2. If no floating IPs are available, click the + button to allocate one from the public pool.
  3. Select the IP and click Associate.

Make a note of the floating IP — Windows will connect to this address.

Using the CLI

The same provisioning steps with the OpenStack CLI:

1# Boot the instance from a new 20 GB volume created from the Ubuntu image
2openstack server create \
3  --image "Ubuntu 24.04 LTS" \
4  --flavor m1.small \
5  --network private-network \
6  --key-name my-keypair \
7  --security-group default \
8  --boot-from-volume 20 \
9  fileserver-01
10

11# Wait for it to become ACTIVE
12openstack server show fileserver-01 -c status
13

14# Allocate and associate a floating IP
15FLOATING_IP=$(openstack floating ip create public -f value -c floating_ip_address)
16openstack server add floating ip fileserver-01 "$FLOATING_IP"
17echo "Floating IP: $FLOATING_IP"

Step 2: Create a Dedicated Security Group for SMB

The default security group is too permissive (or too restrictive, depending on your project) for a file server. Create a security group that opens only the SMB port (TCP 445), and only to the IP addresses your team uses.

Using Horizon

Navigate to Project > Network > Security Groups and click Create Security Group.

  1. Name: fileserver
  2. Description: SMB access for the team file server

Click Create Security Group, then click Manage Rules on the new group.

Add a rule for SMB:

  1. Click Add Rule.
  2. Rule: Custom TCP Rule
  3. Direction: Ingress
  4. Open Port: Port
  5. Port: 445
  6. CIDR: Your team's public IP, in CIDR notation. For a single IP this is 203.0.113.42/32. For an office subnet this might be 203.0.113.0/24. Repeat this rule once per IP range your team uses.

Click Add.

Add a similar rule for SSH (TCP 22) from the same CIDRs so you can administer the server.

Once the security group is configured, attach it to the instance: navigate back to Project > Compute > Instances, open the action menu for fileserver-01, and choose Edit Security Groups. Add fileserver and remove default (unless default is already restricted to your team).

Using the CLI

1# Create the security group
2openstack security group create fileserver \
3  --description "SMB access for the team file server"
4

5# Allow SMB (TCP 445) from your team's CIDR
6openstack security group rule create fileserver \
7  --protocol tcp --dst-port 445 \
8  --remote-ip 203.0.113.0/24
9

10# Allow SSH (TCP 22) from the same CIDR
11openstack security group rule create fileserver \
12  --protocol tcp --dst-port 22 \
13  --remote-ip 203.0.113.0/24
14

15# Attach the new group to the instance and detach default
16openstack server add security group fileserver-01 fileserver
17openstack server remove security group fileserver-01 default
⚠ Never use 0.0.0.0/0 as the remote IP for the SMB rule. Exposing SMB to the public internet is a well-known attack vector. If team members move around, set up a VPN and use the VPN's CIDR.

Step 3: Attach a Volume for Shared Data

Hosting team data on its own Cinder volume — separate from the root disk — lets you grow storage independently, take volume backups, and migrate the share to a new instance without copying files.

Using Horizon

Navigate to Project > Volumes > Volumes and click Create Volume.

  1. Name: fileserver-data
  2. Volume Source: No source, empty volume
  3. Type: Default
  4. Size: 100 GiB (or whatever your team needs — you can extend it later)
  5. Availability Zone: match the zone your instance was launched in.

Click Create Volume. Once the volume status shows Available, click its action menu and choose Manage Attachments, then attach it to fileserver-01. OpenStack assigns it a device name like /dev/vdb.

Using the CLI

1openstack volume create --size 100 fileserver-data
2openstack server add volume fileserver-01 fileserver-data
3openstack server show fileserver-01 -c volumes_attached

Step 4: Format and Mount the Volume on the Instance

SSH into the instance using the floating IP from Step 1 and the keypair you allocated. The default Ubuntu 24.04 username is ubuntu.

1ssh ubuntu@<floating-ip>

Confirm the new disk is visible:

1lsblk

You should see /dev/vdb listed with no partitions and no mount point.

Format the volume with ext4 and mount it at /shared:

1sudo mkfs.ext4 -L shared /dev/vdb
2sudo mkdir -p /shared
3sudo mount /dev/vdb /shared

Add the volume to /etc/fstab so it remounts automatically on reboot. Use the disk label rather than /dev/vdb because device names can shift if other volumes are attached:

1echo 'LABEL=shared  /shared  ext4  defaults,nofail  0 2' | sudo tee -a /etc/fstab

Verify the entry mounts cleanly:

1sudo umount /shared
2sudo mount -a
3df -h /shared

/shared should now show 100 GB of free space.

Step 5: Install and Configure Samba

Install Samba and create the share configuration.

1sudo apt update
2sudo apt install -y samba

Create a directory for team data and set ownership:

1sudo mkdir -p /shared/team
2sudo chown -R nobody:nogroup /shared/team
3sudo chmod 2770 /shared/team

Create a Linux group for Samba users, then create one or more users that will authenticate over SMB. The Linux account does not need a login shell — these accounts exist only for Samba authentication:

1sudo groupadd smbusers
2sudo useradd -M -s /sbin/nologin -G smbusers alice
3sudo smbpasswd -a alice    # prompts for the SMB password
4sudo smbpasswd -e alice    # enables the account

Repeat for each team member, or for a single shared team account if you want a single password for the whole team. Group ownership of the share directory needs to match:

1sudo chgrp -R smbusers /shared/team

Append a share definition to /etc/samba/smb.conf. Replace the existing [global] section's workgroup line if your environment uses a different one; otherwise, add only the share section:

1sudo tee -a /etc/samba/smb.conf > /dev/null <<'EOF'
2

3[team]
4   path = /shared/team
5   valid users = @smbusers
6   browseable = yes
7   writable = yes
8   read only = no
9   create mask = 0660
10   directory mask = 2770
11   force group = smbusers
12EOF

Validate the configuration and restart Samba:

1sudo testparm -s
2sudo systemctl restart smbd nmbd
3sudo systemctl enable smbd nmbd

testparm should report Loaded services file OK. If it reports errors, fix them before continuing — Samba will refuse to start with an invalid config.

Confirm Samba is listening on port 445:

1sudo ss -tlnp | grep ':445'

You should see smbd listening on 0.0.0.0:445.

Step 6: Map the Share as a Network Drive in Windows

From a Windows 10 or 11 workstation on one of the IPs you allowed in Step 2:

Using File Explorer

  1. Open File Explorer.
  2. In the left pane, right-click This PC and choose Map network drive….
  3. Drive: select an available drive letter — F: is conventional for a shared drive.
  4. Folder: enter \\<floating-ip>\team (replace <floating-ip> with the IP from Step 1, for example \\203.0.113.42\team).
  5. Tick Reconnect at sign-in so the drive remounts after every reboot.
  6. Tick Connect using different credentials.
  7. Click Finish.
  1. When prompted, enter the SMB username (e.g. alice) and SMB password from Step 5. Tick Remember my credentials.

After the credentials are accepted, the new drive appears under Network locations in This PC:

Using PowerShell

For scripted deployments or imaging, the same mount via PowerShell:

1$cred = Get-Credential        # prompts for alice / SMB password
2New-PSDrive -Name F -PSProvider FileSystem `
3  -Root "\\203.0.113.42\team" -Credential $cred -Persist

The -Persist flag makes the mapping survive reboots — equivalent to ticking Reconnect at sign-in in File Explorer.

Verify the Share Works

Confirm the mount end-to-end:

  1. In Windows, open the new F: drive in File Explorer. It should be empty.
  2. Create a test file: right-click in F: and choose New > Text Document, name it hello.txt, open it, type a line, save it.
  3. SSH back into the Ubuntu instance and confirm the file appears on the server side:
1   ls -l /shared/team
2   cat /shared/team/hello.txt

The file should be there with smbusers group ownership.

  1. Delete the test file from the Windows side and confirm it disappears on the server.

If all three round-trip without errors, the share is working.

Troubleshooting Common Issues

Windows says "Windows cannot access \\\<ip\>\team"

The connection is being blocked before it reaches Samba. Check, in order:

  • The security group rule from Step 2 includes the public IP your Windows machine is using. Look up your IP at https://whatismyipaddress.com if you are unsure.
  • Samba is running on the server: sudo systemctl status smbd.
  • Port 445 is listening: sudo ss -tlnp | grep ':445'.
  • The Windows machine itself is not blocking outbound 445. Some corporate networks block SMB on the LAN to limit ransomware spread; in that case, set up a VPN to the cloud network.

Authentication fails repeatedly

The Samba password is separate from the Linux password. Reset it on the server:

1sudo smbpasswd alice    # set a new SMB password
2sudo smbpasswd -e alice # ensure the account is enabled

Do not include the domain in the Windows credential prompt — leave it blank or use the floating IP as the "domain" (Windows often pre-fills the local machine name, which will fail).

Files appear on Windows but cannot be opened or saved

This is almost always a Linux permissions issue. Confirm the share directory is owned by smbusers and has the SGID bit set:

1ls -ld /shared/team
2# Expected: drwxrws--- root smbusers

If the SGID bit is missing, reset it:

1sudo chmod 2770 /shared/team

The SGID bit ensures new files inherit the smbusers group rather than the creator's primary group.

The drive disconnects after idle time

Windows aggressively disconnects idle SMB sessions. Add a registry tweak on the client to keep the session alive longer, or set KeepAliveInterval in Samba's smb.conf:

1[global]
2   ...
3   keep alive = 60

Restart smbd after editing.

Performance feels slow

For a single-instance Samba server, expect throughput close to the floating IP's network limit, minus SMB overhead. Specifically:

  • Use a flavor with at least 2 vCPU. Samba is not CPU-heavy for small numbers of users, but encrypting SMB 3 traffic does some work.
  • Place the Cinder volume in the same availability zone as the instance.
  • For teams above ~25 concurrent users, look at scaling vertically (larger flavor) before scaling horizontally.

Related Resources