Issue migrating from one server to another

isaacmananes

Hello everyone!

And thank you so much for your support.

We have been using osticket for a while in an internal environment, running IIS, with PHP 8.2, MySQL 8, without any problems, and now want to migrate to new server and start using it with customers.

We are now migrating this IIS to a ubuntu server running ISPconfig, trying to replicate PHP, MySQL to make it easy, this is our information from one and another host:

New instance:

Old one:

Everything works fine but files. We store files at filesystem, and we noticed when migrating, the url for a same file changes, it has completely different signature.

https://newinstance.com/file.php?key=p4dsfldtddont68wdd6efvxmojf97u9c&expires=1759881600&signature=5ded6...&id=685

https://soporte.salamancapc.com/file.php?key=p4dsfldtddont68wdd6efvxmojf97u9c&expires=1759881600&signature=1fe0ebd...&id=685

Both have the same upload to filesystem configuration:

If we dump the new database and restore it in the old one, it start working again, so we've discarded a database migration issue, but cannot find a solution to this issue.

Are we missing any configuration related to server / instance signature that should be done when migrating?

Thank you!

KevinTheJedi

isaacmananes

The signature on attachment urls will be different from time to time even on your old server as it includes the expiration (which obviously changes). The key is the main part; as long as that stays the same. Did you actually migrate all the attachments on the filesystem from IIS to the same location on your Ubuntu server?

If you did migrate them then it could be this common pitfall:
To preface, when storing files on the file system we use the first letter/number of the key, create a folder on the file system (if it doesn’t exist) with the name being the letter/number, then store the file there. On Linux it’s case sensitive meaning if your key starts with aHdT… then it will be stored in a/ but if it starts with AHdT… it will be stored in A/. The problem is on IIS it is not case sensitive meaning both aHdT… and AHdT… will be stored in a/. When you migrate the files from IIS to Linux a common pitfall is Linux will not create the different case sensitive folders for you; only the ones it receives from IIS. So when Linux goes to find AHdT… it’s looking for A/ which doesn’t exist. So you will need to write a script or something to create the different case sensitive folders, move the files where they need to go based on the first letter/number of the file name, and retest.

Cheers.

isaacmananes

Thank you very much for your support — this was the key to solving our problem!

At first, I thought the folder creation wasn’t case-sensitive, assuming it was random and that once a folder was created everything went there.

I tested more than 20 attachments, only to find that some were corrupt and some were missing, not realizing there were actually two different issues.

I wrote a small script thanks to your feedback to reorganize the folders. I’m happy to share it — you only need to set your upload folder path and run it.

It includes a DRYRUN option so you can test and review the log safely before moving files for real (set DRYRUN=0 to apply the changes).

#!/usr/bin/env bash
set -euo pipefail

# === SETTINGS ===
BASE="upload_path"  # ← your actual upload path
DRYRUN=1          # 1 = simulate (no move), 0 = move for real
LOG="/var/log/osticket_attachments_reorg.log"

# Site user/group in ISPConfig (adjust if different)
WEBUSER="webuser"
WEBGROUP="clientnumber"

umask 027

touch "$LOG" && chown "$WEBUSER":"$WEBGROUP" "$LOG" || true
echo "=== $(date '+%F %T') Start reorganization in $BASE (DRYRUN=$DRYRUN) ===" | tee -a "$LOG"

# Traverse files in BASE/<folder>/<file>
find "$BASE" -maxdepth 2 -type f -printf '%h/%f\n' | while IFS= read -r path; do
  dir=$(dirname "$path")
  file=$(basename "$path")
  [[ -z "$file" ]] && continue

  first="${file:0:1}"                     # first character of the key
  dest_dir="$BASE/$first"                 # correct (case-sensitive) folder

  if [[ "$dir" != "$dest_dir" ]]; then
    # Create destination folder if it doesn’t exist and fix ownership
    if [[ ! -d "$dest_dir" ]]; then
      mkdir -p "$dest_dir"
      chown "$WEBUSER":"$WEBGROUP" "$dest_dir" || true
      chmod 0750 "$dest_dir" || true
    fi

    if [[ "$DRYRUN" -eq 1 ]]; then
      echo "[DRYRUN] mv '$path' '$dest_dir/'" | tee -a "$LOG"
    else
      # Move without overwriting existing files (rare cases)
      if [[ -e "$dest_dir/$file" ]]; then
        echo "[SKIP] already exists '$dest_dir/$file' — check conflict" | tee -a "$LOG"
      else
        echo "[MOVE] '$path' -> '$dest_dir/$file'" | tee -a "$LOG"
        mv "$path" "$dest_dir/$file"
        chown "$WEBUSER":"$WEBGROUP" "$dest_dir/$file" || true
        chmod 0640 "$dest_dir/$file" || true
      fi
    fi
  fi
done

echo "=== $(date '+%F %T') End reorganization (DRYRUN=$DRYRUN) ===" | tee -a "$LOG"

After fixing this, we could finally see some files (like .txt), but others still didn’t open correctly — even though they existed. When we started comparing checksums, we noticed that every file was slightly different.

I even allowed direct access to the upload folder and tested one of the files I had uploaded from my computer; it didn’t work once accessed without an extension, but it did work if I uploaded it with an extension.

That’s when we discovered that FileZilla was using Auto transfer mode instead of Binary, so it was re-encoding (compressing) the files during transfer.

Once we deleted everything, re-uploaded all attachments in Binary mode, and ran the script again, everything started working perfectly.

Everything was possible thanks to your help — thank you again! 🙌