You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you point gamevault's backend to a directory that has a subdirectory it cannot enter/read from due to insufficient permissions, it will endlessly restart and fail each time it finds that it cannot enter/read the subdirectory, rendering the backend unusable without changing permissions on the subdirectory or moving gamevault's game directory elsewhere.
This makes it impossible to serve the game library from the root directory of any drive in Linux due to the automatic creation of the lost+found directory on all volumes. As a workaround, you'll need to create a subdirectory on that new volume to use as your library folder.
To Reproduce
Steps to reproduce the behavior:
Create a new volume to use as Gamevault's game directory - either by formatting a new drive or creating a new empty virtual drive on a Linux machine.
Start gamevault backend.
Watch docker logs/docker ps which will show the gamevault backend endlessly restarting.
Expected behavior
Gamevault should skip over the subdirectory it has no permissions to read and continue starting up.
Additional context
This may sound like a strange issue, however it is very easily caused by creating a new volume in Linux and using the root directory of that new volume as the directory that your game library is served from. This is because Linux automatically adds a "lost+found" subdirectory to every new volume created whose permissions cannot easily be changed (nor should they).
I came across this issue by running gamevault in a linux container on proxmox. I decided to create a separate volume specifically for holding my library of games which automatically creates the lost+found directory when the volume comes online. Because this directory does not have the proper permissions set to allow gamevault to read it (and again, it SHOULD NOT anyways), gamevault dies repeatedly.
I would not be surprised if gamevault would react the same way if permissions would not allow gamevault to read a specific file in the game library directory as well, something else to test.
The text was updated successfully, but these errors were encountered:
If you point gamevault's backend to a directory that has a subdirectory it cannot enter/read from due to insufficient permissions, it will endlessly restart and fail each time it finds that it cannot enter/read the subdirectory, rendering the backend unusable without changing permissions on the subdirectory or moving gamevault's game directory elsewhere.
This makes it impossible to serve the game library from the root directory of any drive in Linux due to the automatic creation of the lost+found directory on all volumes. As a workaround, you'll need to create a subdirectory on that new volume to use as your library folder.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Gamevault should skip over the subdirectory it has no permissions to read and continue starting up.
Additional context
This may sound like a strange issue, however it is very easily caused by creating a new volume in Linux and using the root directory of that new volume as the directory that your game library is served from. This is because Linux automatically adds a "lost+found" subdirectory to every new volume created whose permissions cannot easily be changed (nor should they).
I came across this issue by running gamevault in a linux container on proxmox. I decided to create a separate volume specifically for holding my library of games which automatically creates the lost+found directory when the volume comes online. Because this directory does not have the proper permissions set to allow gamevault to read it (and again, it SHOULD NOT anyways), gamevault dies repeatedly.
I would not be surprised if gamevault would react the same way if permissions would not allow gamevault to read a specific file in the game library directory as well, something else to test.
The text was updated successfully, but these errors were encountered: