[Bug]: Linux shared-folder lookup in a user namespace corrupts cached ownership and denies access outside the namespace #895

Version

7.2.14

Host OS Type

Linux

Host OS name + version

Pop!_OS 22.04 LTS

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

Ubuntu 26.04.1 LTS

Component

Guest Additions/Shared Folders

What happened?

Previously accessible directories in a read-only VirtualBox share became selectively inaccessible from the Linux guest. The share, named host, exposes the host user's home directory and is automounted at /media/sf_host. My user first noticed the problem while working with Codex to locate and copy documents from the host's pCloud and Dropbox directories. They did not recall changing the share configuration or permissions before the failure.

The symptoms were confusing: ls /media/sf_host/pcloud could list the expected top-level contents, but a recursive find failed with Permission denied. My user ran the same find in a separate ordinary guest terminal and confirmed that it also failed. Their tree reported [error opening dir] for several, but not all, pCloud subdirectories. I then ran a broader tree /media/sf_host/, which showed many other ordinary host directories were inaccessible while parts of pCloud remained readable.

My user also observed the problem in the guest's Files application, where affected directories displayed lock icons. Opening desktop (a symlink to Desktop) produced: "You do not have the permissions necessary to view the contents of "desktop"." This was therefore not confined to Codex or its sandbox.

My initial inspection showed a discrepancy between the mount's configured ownership (uid=0,gid=981,dmode=0770,fmode=0770) and guest-visible metadata reporting 65534:65534 (nobody:nogroup) with mode 0770. The guest account was a member of vboxsf. These observations did not initially explain why some paths remained readable and others did not; changing group membership was not an adequate explanation or remedy.

At my user's request, I compared the guest configuration with the expected setup and found no configuration error explaining the failure. I subsequently traced the suspected cause to the driver's inode ownership initialization and developed a standalone unshare reproduction. My user helped simplify it into the two-order command below and ran it to confirm the result.

Expected: the authorized guest user should retain access to the shared directories. A read-only inspection by another process, including one in a user namespace, should not change ownership or access for ordinary guest processes. The controlled reproduction below isolates that access-order dependency without requiring Codex or any other application sandbox.

Suspected cause

The installed Guest Additions source, src/vboxguest-7.2.14/vboxsf/utils.c, contains the following in vbsf_init_inode():

inode->i_uid = make_kuid(current_user_ns(), pSuperInfo->uid);
inode->i_gid = make_kgid(current_user_ns(), pSuperInfo->gid);

These assignments are also present in the public main-branch source.

In the standalone reproducer, the requesting namespace maps only internal UID/GID 1000 to the launching root identity. The mount's configured UID 0 and GID 981 have no mapping there. Interpreting the mount options in the lookup process's namespace appears to produce invalid IDs which are then stored in the shared inode. This is an explanation inferred from source inspection and the experiments, rather than a tested patch.

Related reports and scope

Flathub qBittorrent issue #62, opened in 2021, describes very similar ownership changes, recovery after remounting, and successful sandboxed access when the ordinary application accesses the directory first. An August 2026 comment reports continued failures. Whether it has precisely the same cause has not been independently verified.

We have reproduced this on 7.2.14. We have not tested newer releases or development builds; finding the same assignments in main is not a runtime test of those versions.

How can we reproduce this?

Run the following block in an ordinary non-root guest Bash terminal. It tests both lookup orders, unmounting between them to reset the inode cache, and removes its mount directory afterward. This exact block was tested on the configuration above on 2026-10-07.

DO NOT RUN AS ROOT

Run the block from your ordinary guest user's shell, not a root shell or under an outer sudo. The unprefixed stat and ls must test that user's access, not root's privileges. Keep the individual sudo commands inside the block as written.

The second ls is expected to fail; any other error invalidates the comparison and may require manual unmounting before retrying.

(
    repro_mount=/mnt/vbox-userns-test
    repro_share=host
    repro_folder=vbox_test
    repro_gid=981
    sudo mkdir "$repro_mount"
    sudo mount -t vboxsf -o "ro,nodev,nosuid,uid=0,gid=$repro_gid,dmode=0770,fmode=0770" "$repro_share" "$repro_mount"
    stat -c '%u:%g %a %n' "$repro_mount/$repro_folder"
    sudo unshare --user --map-user=1000 --map-group=1000 -- stat -c '%u:%g %a %n' "$repro_mount/$repro_folder"
    ls "$repro_mount/$repro_folder" # Expected: succeeds.
    sudo umount "$repro_mount"
    sudo mount -t vboxsf -o "ro,nodev,nosuid,uid=0,gid=$repro_gid,dmode=0770,fmode=0770" "$repro_share" "$repro_mount"
    sudo unshare --user --map-user=1000 --map-group=1000 -- stat -c '%u:%g %a %n' "$repro_mount/$repro_folder"
    stat -c '%u:%g %a %n' "$repro_mount/$repro_folder"
    ls "$repro_mount/$repro_folder" # Expected on affected driver: Permission denied.
    sudo umount "$repro_mount"
    sudo rmdir "$repro_mount"
)

VBox.log

Output from my user's test run, omitting the sudo password prompt:

0:981 770 /mnt/vbox-userns-test/vbox_test
1000:65534 770 /mnt/vbox-userns-test/vbox_test
VBox.log
65534:65534 770 /mnt/vbox-userns-test/vbox_test
65534:65534 770 /mnt/vbox-userns-test/vbox_test
ls: cannot open directory '/mnt/vbox-userns-test/vbox_test': Permission denied

In the ordinary-first phase, ownership is correctly initialized as 0:981. The namespace's 1000:65534 is the expected translation of that ownership into its own ID mapping, and the ordinary listing succeeds (VBox.log is the test directory's sole entry).

After remounting, the namespace-first lookup produces 65534:65534. Crucially, the following ordinary lookup now also reports 65534:65534, and the ordinary listing fails. The same directory and mount options therefore give different access results solely from reversing lookup order.

On this Ubuntu installation, unprivileged unshare --user --map-current-user was denied while writing uid_map, so the reproducer uses sudo to establish the namespace without changing system-wide namespace restrictions.

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.