When you install a mod for a Steam game on Linux, it may not work correctly in the game. In many cases this is due to the differences in the way Windows and Linux interpret file names. In Windows, file names are case-insensitive, meaning MyFile.txt and myfile.txt refer to the same file on the disk. In contrast, on Linux file names are case sensitive, so those two file names would refer to different files.

Since Windows dominates the gaming scene, most mods are developed on Windows computers, where the casing of file names doesn’t matter. This leads to modders getting lazy with their filenames and often using a different casing than the game uses. While the mod might work without issue on Windows, on Linux the mod will fail in unexpected ways when it tries to reference files that may or may not exist (at least, as Linux sees them).

The solution to this problem is to install a virtual file system on your Linux computer that will emulate a Windows file system with case insensitive filenames. When the mod loads files from this virtual file system, it loads files with any casing correctly while the game itself continues natively on Linux. The steps below will show you how to create the virtual file system and then mount it for use with your games. You don’t have to reinstall your mods this way either; they can be copied over to the new file system and should start working immediately.

Create the virtual file system

To start with, you need to create the virtual file system. We will be using the vFAT file system for this purpose. vFAT is a lightweight, Windows-compatible file system with native support in the Linux kernel. It’s significantly faster to use compared with a full NTFS file system, since NTFS provides a bunch of features that are not needed for a small virtual file system and it requires additional driver support in Linux.

To create the virtual file system, run this command:

sudo mkfs.vfat -C -F 32 /opt/steam-workshop.img 2097152

• mkfs.vfat - This command creates a virtual file system using the FAT file system format.
• -C - This option specifies that the command should create a file instead of using an existing physical device like a USB stick.
• -F 32 - This option specifies using FAT32 format, allowing the largest file sizes in the FAT family.
• /opt/steam-workshop.img - This specifies the file where you want to file system to be stored. This can be any place and any name you want. If you use a different path or name, be sure to change in the rest of the commands below.
• 2097152 - This is the size of the file system you want to create. This number is the number of file system blocks, which the mkfs.vfat command defaults to 1024 bytes each, or 1 KB. So this number should be how many kilobytes the file should be. E.g. 1 MB is 1024 KB, and 1 GB is 1048576 KB. I chose 2097152 blocks for mine, which equates to 2 GB. You can adjust this value depending on how many mods you want to be able to install at one time.

Run this command as root on your system and verify it created a new file at the specified path. It is already formatted with the FAT32 file system, so next we need to use it.

Mounting the virtual file system

You can’t access the virtual file system directly through the file we created in the last step; it must be mounted to the local file system as a virtual block device so it can be used by the operating system. To do that, we’ll use a loopback device.

Choosing a loopback device

Loopback devices typically use the naming convention /dev/loopXX where XX is any numeric digit. To see if you have any loopback devices in use already, you can run the command losetup -l. If you don’t see loopback devices listed, then you are free to pick any number, or start at 0. If you do see any loopback devices, just choose a number that’s not in use. You can either use the next available number, or choose an arbitrary higher number to leave room for other programs creating loopback devices.

To create the loopback device, run the following command:

losetup /dev/loopXX /opt/steam-workshop.img

• losetup - This is the name of the program that creates, manages, and deletes loopback devices on your system.
• /dev/loopXX - This is the loopback device to create. Replace the XX with number you chose previously.
• /opt/steam-workshop.img - This is the path to the virtual file system you created in the previous section.

If the command ran successfully, the virtual file system file is now running as a block device on your system. The next step is to mount it so your operating system can access the files in it.

Manually mounting the virtual file system

Next, you can mount the virtual file system by running the following command:

sudo mount -o uid=<user>,gid=users,fmask=113,dmask=002,iocharset=iso8859-1 /dev/loopXX "/path/to/steam/steamapps/workshop/content"

• sudo mount - This command mounts file systems into your root file system for the operating system to use. It must always be run as the root user.
• -o uid=<user>,gid=users,fmask=113,dmask=002,iocharset=iso8859-1 - This specifies the options for the file system to be mounted. Replace <user> with your username. The uid and gid options specify the user and group that the file system should be mounted with. The fmask and dmask options set the file permissions. And finally iocharset sets the character encoding for filenames.
• /dev/loopXX - This is the loopback device you created previously. Replace XX with the number of the loopback device you created.
• "/path/to/steam/steamapps/workshop/content" - This is the path to the workshop content (mods + other downloadable content from Steam) on your computer. It can vary from system to system and the way Steam was installed. But once you find the directory steam is installed at, inside you should find the steamapps/workshop/content folder where any current mods for any game are installed. Note the double quotes around the path. If there’s already content inside this folder, be sure to back it up before mounting this directory! It’s as simple as cp -r content/ content_old/.

After running this command, the virtual file system should be mounted in Steam’s content directory, meaning any files the Steam workshop downloads to your computer will be stored in the virtual file system instead of on your disk.

If you backed up existing files from the content directory, you can use this command to restore those files:

cp -a content_old/* content/

The -a flag will recursively copy all files, preserving file permissions, ownership, timestamps, and extended attributes. Just make sure the content/ directory is empty, as this command will overwrite any files with the same name.

Automatically mounting the file system

If you followed the instructions previously to manually mount the virtual file system, you will notice that it will become unmounted every time you turn off the computer. You can create a systemd service to automatically mount the file system at boot.

First, create the service file using your favorite text editor. I’m using nano because it’s objectively the best. The file can be named whatever you want, as long as it ends with .service and can be found in the /etc/systemd/system/ directory. If you use a different service name, be sure to change the name in the rest of the commands.

sudo nano /etc/systemd/system/steam-workshop.service

And add the following content to it:

[Unit]
Description=Steam Workshop virtual drive device and mount
After=local-fs.target
Before=graphical.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/sbin/losetup /dev/loopXX /opt/steam-workshop.img && /bin/mount -o uid=<usr>,gid=users,fmask=113,dmask=002,iocharset=iso8859-1 /dev/loopXX "/path/to/steam/steamapps/workshop/content"'
ExecStop=/bin/bash -c '/bin/umount "/path/to/steam/steamapps/workshop/content" && /sbin/losetup -d /dev/loopXX'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Here are the important things to note about this service file:

• Description= - The description for this systemd service. You can put anything here.
• After=local-fs.target - This will prevent this service from starting until after the local file system has been initialized. This is important because we are loading from an existing file on the local file system, so we have to make sure the local file system is fully initialized before mounting the virtual file system.
• Before=graphical.target - This specifies that the graphical subsystem should not start until this service completes. That means the virtual file system should be mounted before the graphics system is initialized. This is helpful if you have Steam set to start at system startup: it will prevent Steam from auto-starting before the virtual file system has been mounted, causing Steam to see an empty content/ directory.
• Type=oneshot - This specifies that this command will run a single command and terminate (as opposed to a daemon that runs forever). This informs systemd how to manage and report the status of this service.
• ExecStart= - This is what systemd will run when it starts your service. It should look similar to the steps to manually mount the virtual file system. Things to note about this command:
  • It combines both the creation of the loopback device and mounting it into one command, joined by &&. The whole thing is wrapped in a call to /bin/bash -c '...' because systemd can only run one command. Note the single quotes; since the command uses double quotes around the file path, we use single quotes here to not interfere with those.
  • We use the full path to /sbin/losetup instead of just the command name itself. Since this is running early on in the boot process, it’s safer to refer to the executable directly instead of relying on the PATH environment variable being set up correctly.
• ExecStop= - This is the command that’s run when systemd attempts to stop this service; either automatically or when you run systemctl stop steam-workshop.service (or whatever you named the service). It’s the same steps in ExecStart but opposite and in reverse order: unmounting the virtual file system and destroying the loopback device. This allows systemd to cleanly shutdown and free those resources either during system shutdown or if you manually specify it on the command line. Without this step you may be stuck with leftover resources not cleaned up preventing you from remounting things.
• RemainAfterExit=yes - This tells systemd that the service will exit after starting but to mark it as still active (as long as it ran the startup command successfully). This will cause systemd to report the status of this service correctly, as well as making sure the ExecStop command is run during shutdown. Without this command systemd would consider this service inactive after it finishes running ExecStart and wouldn’t run ExecStop later.
• WantedBy=multi-user.target - This indicates to systemd when to run this script during boot up.

After creating the service, enable and start it with sudo systemctl enable --now steam-workshop.service. Now the virtual file system will be created and mounted automatically when the computer boots up, ready for Steam to use. Since it’s mounted in the directory Steam expects workspace content to be, any newly subscribed content will automatically be added to the virtual file system.