Processing 200 GB of Google Takeout on a Synology NAS — Part 1: The Container

I moved off Google Photos onto Synology Photos. My NAS is a DS225+, which runs Container Manager, so the migration never needed a laptop in the loop.

Synology’s Cloud Sync could have pulled the export directly, but that means authorizing the NAS against my personal Google account and leaving a long-lived credential on a device I will not audit again for a year. For a one-time migration, that is a permanent risk for a temporary convenience. So I downloaded the Takeout archives to my laptop and uploaded them to the NAS instead.

That left 200 GB of zips — 21 archives, ~10 GB each — sitting on the Synology, and no good way to work on them:

• The laptop cannot hold them. 200 GB of archives plus their extracted output is more free disk than I have.
• Small files, not bytes, are the bottleneck. Extracted, Takeout is hundreds of thousands of JPEGs, HEICs, MP4s, and one JSON sidecar per file. Copying that over SMB is dominated by per-file round trips. Extracting locally and copying back is the worst possible shape of transfer.

The data was already on the NAS. The compute had to come to it.

Not just extraction, either. Takeout does not write your metadata back into your files — it strips capture time, GPS, and album data into .json sidecars. Import as-is and Synology Photos sorts your library into nonsense. Fixing that means many passes over the data, next to the disks.

So: a small Docker image giving me an SSH session on the NAS with the Takeout volume mounted. This post covers the container and unpacking the archives. Part 2 covers the sidecars and EXIF repair.

graph LR
    A[Laptop] -->|SSH 2222| B[Synology DS225+]
    B --> C[Container: ssh_jump_box]
    C --> D[sshd]
    C --> E[7-Zip]
    C -->|bind mount| F[Takeout share]

Prerequisites

#

• Synology NAS on DSM 7.x with Container Manager
• SSH temporarily enabled on the NAS (Control Panel → Terminal & SNMP) — we turn this back off at the end
• An account in the administrators group
• Free space equal to the extracted output, on top of the archives

DSM 7.2+ ships Compose v2, so it is docker compose, not docker-compose.

Step 1: The Dockerfile

#

1
2
3

FROM linuxserver/openssh-server:latest

RUN apk add --no-cache p7zip

linuxserver/openssh-server handles host key generation, dropping to a non-root user, and mapping that user to an arbitrary host UID/GID. The base is Alpine, so it is apk, not apt-get — the most common copy-paste failure here.

p7zip installs /usr/bin/7z. You will see variants that also install unzip; it is redundant, since 7z x reads ZIP and 7z t tests integrity. Part 2’s tooling gets appended to this same line.

Step 2: The compose file

#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

services:
  ssh-jump:
    build:
      context: .
    container_name: ssh_jump_box
    environment:
      - PUID=1026
      - PGID=100
      - TZ=Asia/Kolkata
      - PASSWORD_ACCESS=true
      - USER_NAME=jump
      - USER_PASSWORD=password@123   # change me
      - PUBLIC_KEY_FILE=/keys/authorized_key.pub
      - SUDO_ACCESS=false
      - LOG_STDOUT=true
    volumes:
      - ssh_config:/config
      - ./authorized_key.pub:/keys/authorized_key.pub:ro
      - /volume1/homes/YOUR_USER/GooglePhotosBackup:/backup
    ports:
      - "2222:2222"
    restart: unless-stopped

volumes:
  ssh_config:
    driver: local

No version: key — it is obsolete in Compose v2.

Step 3: Generate a key and deploy

#

1
2
3
4
5

ssh-keygen -t ed25519 -f ~/.ssh/synology_jump -C "synology-jump-box"

ssh admin@synology.local 'sudo mkdir -p /volume1/docker/ssh_jump_box'
scp Dockerfile docker-compose.yml admin@synology.local:/volume1/docker/ssh_jump_box/
scp ~/.ssh/synology_jump.pub admin@synology.local:/volume1/docker/ssh_jump_box/authorized_key.pub

Copy the .pub, never the private key.

From the CLI:

1
2
3
4

ssh admin@synology.local
cd /volume1/docker/ssh_jump_box
sudo docker compose up -d --build
sudo docker compose logs --tail 30

Three lines confirm it worked: sshd is listening on port 2222, User/password ssh access is enabled., and Public key from file added.

From Container Manager (DSM 7.2; labels shift between versions):

1. Container Manager → Project → Create
2. Name it ssh_jump_box, set Path to the folder above
3. Source → Use existing docker-compose.yml
4. Next past the web-portal step, then Done

Day to day, Project → select → Action handles Start / Stop / Restart. After editing the compose file or Dockerfile use Action → Build — a plain Start reuses the stale image and silently ignores your edits. Container → Details → Log shows the sshd output, and Container → Terminal gives you a browser shell if you lock yourself out (as root, which matters below).

Step 4: Connect

#

1
2

ssh -p 2222 -i ~/.ssh/synology_jump jump@synology.local   # key
ssh -p 2222 jump@synology.local                           # password

Verify before doing anything else:

1
2

id          # must show your PUID/PGID, not 0 or 911
df -h /backup

911 means PUID never applied — those vars are read at container creation, so it needs a rebuild, not a restart.

On space: extracted Takeout is roughly the same size as the archives, since photos and video are already compressed and ZIP achieves nothing on them. Budget a full second copy.

Step 5: Extract

#

Google Takeout’s numbered parts are independent ZIP files, not split volumes — -002.zip is a complete archive holding a different subset. Extract each on its own; a corrupt part costs you that part, not the set.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

cd /backup
nohup sh -c '
for file in takeout-*.zip; do
  [ -f "$file" ] || continue
  echo "=== $(date): $file"
  if 7z x -y "$file" -o. ; then echo "OK: $file"; else echo "FAILED: $file"; fi
  df -h /backup | tail -1
done
echo "ALL DONE"
' > /backup/extraction.log 2>&1 &

Why each piece:

• Glob, do not count. Your part count depends on the archive size you picked at export. Worse, {1..21} does not work here at all — the shell is BusyBox ash, which passes brace expansions through literally, so the loop matches nothing and fails quietly enough that you walk away thinking it started.
• nohup … & — a 200 GB job outlasts every laptop lid.
• -y — otherwise an overwrite prompt blocks a detached job forever.
• Exit status and df per part — across 21 parts one truncated download is realistic, and you want it named in the log, with a running space forecast beside it.
• Log to /backup, not /tmp — container /tmp does not survive a restart.

Watch it with tail -f /backup/extraction.log. If space is tight, swap the OK: line for rm -f "$file" to delete each archive as it succeeds.

Debugging file permissions

#

This cost me the most time. Nearly every confusing failure traces to one cause: three identities write to that folder and disagree.

Compare numeric IDs, always. The container has no view of DSM’s user database, so the same UID shows a different name on each side and ls -l misleads you. Use ls -ln inside the container and on the NAS, and compare numbers.

Ten seconds of preflight beats an afternoon of this:

1

touch /backup/.permtest && ls -ln /backup/.permtest && rm /backup/.permtest

Turn DSM SSH back off

#

Do this once the container is running. DSM’s own SSH was only needed to deploy, and it is by far the most dangerous thing in this setup: it logs in as an administrator with full access to every volume, every share, and sudo. The container’s sshd is the opposite — unprivileged, no sudo, and it can see exactly one folder.

Control Panel → Terminal & SNMP → uncheck Enable SSH service → Apply.

Your workspace keeps running. Port 2222 into the container is unaffected, Container Manager handles start and stop from the UI, and its built-in terminal covers anything else. Re-enable DSM SSH only when you actually need it, and turn it off again after.

Other security notes

#

• Do not commit the password. Once it is in git history, editing it later does not help. Use a gitignored .env, or USER_PASSWORD_FILE pointing at a mounted file.
• Drop to key-only once the key works: set PASSWORD_ACCESS=false and rebuild.
• Do not forward 2222 through your router. LAN or VPN only. A non-standard port buys nothing against a scanner.
• Mount the narrowest path that works. Mounting /volume1 hands anything that gets in your entire NAS.
• Stop the container between sessions — Action → Stop. A stopped container has no listening port.

Note that keys are only ever appended to authorized_keys. Deleting PUBLIC_KEY_FILE from your compose file does not revoke that key — it is still in the named volume. To actually revoke, edit the file or down -v and rebuild.

Cleanup

#

1
2

cd /volume1/docker/ssh_jump_box
sudo docker compose down -v          # container, network, and the ssh_config volume

Extracted photos are untouched — they live on the bind mount, not the volume. To remove the project directory, read the path character by character before pressing enter; a typo in sudo rm -rf against /volume1 is not something the recycle bin will help with.

What’s next

#

200 GB never crossed the network again, and DSM stayed stock — no Entware, no community package to break on the next upgrade, just two short files. Swap p7zip for ffmpeg, rsync, or exiftool and the same disposable workspace handles a different job against data already on the NAS.

Part 2 picks up where the zips end: what Takeout actually gives you, why timestamps and GPS are wrong on import, how the .json sidecars map onto media files, and how to write that metadata into EXIF before Synology Photos ever sees it.

References

#

• linuxserver/openssh-server
• 7-Zip command line
• Compose file reference
• Synology Container Manager