Vagrant Synced Folder Permission Mismatch Between Local Development and CI Production Environments

Direct answer

Yes. Make ownership a property of the guest, not the host. Use a dedicated guest build account with a fixed UID/GID and set explicit ownership on the synced folder. Do not try to make every CI host match your laptop UID; that is the fragile part.

Likely explanation vs confirmed facts

Likely explanation: your CI runner has a different effective UID/GID than your local host. With Linux shared-folder or rsync workflows, the guest then sees files as an unexpected numeric owner, so the build user cannot read or write. CI image changes or OS upgrades can shift the runner UID while your local machine stays the same.

Confirmed behavior to rely on: Vagrant synced folders support explicit ownership configuration; rsync is one-way by default; Windows SMB does not map a Windows account to a Linux UID by equality; SELinux or AppArmor can still deny access even when POSIX ownership looks correct.

What to change

1. Create one fixed build identity in the guest. Pick IDs your base image does not already use:

   groupadd -g 1050 build
   useradd -m -u 1050 -g 1050 build

2. For Linux shared-folder providers, map the folder to that identity instead of relying on the host UID:

   config.vm.synced_folder ".", "/vagrant",
     type: "virtualbox",
     owner: "build",
     group: "build",
     mount_options: ["uid=1050", "gid=1050", "dmode=775", "fmode=664"]

   Use either owner/group or numeric mount_options consistently for your provider; do not assume every provider honors the same options.
3. For rsync, control permissions during transfer rather than trying to preserve the host identity. Verify the exact options your installed rsync supports before adding them:

   rsync --help | grep -E 'chmod|chown|usermap|groupmap'

   Then use only documented options, for example permission and time flags. Do not rely on a --chown option unless your rsync version documents it.
4. On Windows SMB, use stable SMB credentials from CI secrets and set guest mount ownership explicitly. Do not expect the Windows account SID to equal a Linux UID.

Provisioners and UID matching

A provisioner can create the fixed guest user or chown the mounted path after it appears, but it cannot change the host's UID. If the host identity is known at runtime, you can align the guest user to that UID, but that reintroduces variability across machines. Prefer a fixed guest identity. If you must change an existing user's UID/GID, be careful: usermod and groupmod can orphan ownership on existing files.

Mechanism comparison

Verify after applying changes

Reload or re-sync the folder, then check numeric ownership and write access inside the guest:

ls -ln /vagrant
id build
stat -c '%u %g %a %n' /vagrant
touch /vagrant/.write-test && rm /vagrant/.write-test

One detail would change the recommendation: does CI need files written inside the guest to persist back to the host? If yes, rsync alone is the wrong default because it is one-way; use a shared-folder or SMB mount with explicit ownership, or add an explicit reverse sync step.