Permission troubles using RomM

post your compose file in a code box and also an ls -la of the data directory holding your rom files in another code box. Please be sure to mask any information such as domains and logins for security purposes. No need to mask drive uuid paths or internal ip addresses (like 192.168.x.x)

Thread

[How-To] Post content in a code box

Whenever you want to post output from the command line or a compose file, please post it inside a code box.

1. To open a code box press the </> button in the toolbar of the box in which you write the post (see picture below)
2. Copy and paste the output of a command or code inside
3. Hide sensitive data, such as passwords, email addresses or web domains
4. Do not hide non-sensitive data like uuid of drives or device names as they might help to trouble shoot problems
5. When posting output, please post
   • the command

…

macom

Dec 27th 2024

Also a screen shot of the RomM user or an id RomM would be helpful.

These 3 items should give all the configuration and permissions information required to try to help you.

This shows the most common error with people using docker apps on mergerfs pools.

Do not use config, database, caches or redis folders on split drives.

You need those on single drive paths.

Also, recheck your library path since is pointing to the root of the Pool and it needs to live on a subfolder.

Quote from quote241

Alrighty, my compose;

Code

# version: "3"

volumes:
  mysql_data:
  romm_resources:
  romm_redis_data:

services:
  romm:
    image: rommapp/romm:latest
    container_name: romm
    restart: unless-stopped
    environment:
      - PUID=1004
      - PGID=1005
      - HLTB_API_ENABLED=true
      - SCAN_WORKERS= 5
      - SCAN_TIMEOUT= 43200
      - DB_HOST=romm-db
      - DB_NAME=romm # Should match MARIADB_DATABASE in mariadb
      - DB_USER= # Should match MARIADB_USER in mariadb
      - DB_PASSWD= # Should match MARIADB_PASSWORD in mariadb
      - ROMM_AUTH_SECRET_KEY= # Generate a key with `openssl rand -hex 32`
      - IGDB_CLIENT_ID=
      - IGDB_CLIENT_SECRET=
      - SCREENSCRAPER_USER=# These are the recommended metadata providers
      - SCREENSCRAPER_PASSWORD=# https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#screenscraper
      - RETROACHIEVEMENTS_API_KEY= # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#retroachievements
      - STEAMGRIDDB_API_KEY= # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#steamgriddb
      - HASHEOUS_API_ENABLED=true # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#hasheous
    volumes:
      - /srv/mergerfs/BigPool/romm/resources:/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)
      - /srv/mergerfs/BigPool/romm/redis-data:/redis-data # Cached data for background tasks
      - /srv/mergerfs/BigPool:/romm/library # Your game library. Check https://github.com/rommapp/romm?tab=readme-ov-file#folder-structure for more details.
      - /srv/mergerfs/BigPool/romm/assets:/romm/assets # Uploaded saves, states, etc.
      - /srv/mergerfs/BigPool/romm/config:/romm/config # Path where config.yml is stored
    ports:
      - 1025:8080
    depends_on:
      romm-db:
        condition: service_healthy
        restart: true

  romm-db:
    image: mariadb:latest
    container_name: romm-db
    restart: unless-stopped
    environment:
      - MARIADB_ROOT_PASSWORD=
      - MARIADB_DATABASE=romm
      - MARIADB_USER=
      - MARIADB_PASSWORD=
    volumes:
      - mysql_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 30s
      start_interval: 10s
      interval: 10s
      timeout: 5s
      retries: 5

Display More

output of ls -la inside the roms folder and on a level up from there;

Code

$ cd /srv/mergerfs/BigPool/
$ ls -la roms
total 88
drwxrwsrw-+ 13 root users 4096 Mar  6 00:58 .
drwxrwsrw-+  7 root users 4096 Mar  7 10:12 ..
drwxrwsrw-+  2 root users 4096 Feb 28 21:39 3ds
drwxrwsrw-+  2 root users 4096 Mar  4 00:47 android
drwxrwsrw-+  2 root users 4096 Feb 28 21:43 bios
drwxrwsrw-+  2 root users 4096 Feb 28 21:38 gb
drwxrwsrw-+  2 root users 4096 Feb 28 21:38 gba
drwxrwsrw-+  2 root users 4096 Feb 28 21:38 gbc
drwxrwsrw-+  2 root users 4096 Feb 28 21:39 gc
drwxrwsrw-+  2 root users 4096 Jan 24 20:12 genesis
drwxrwsrw-+  2 root users 4096 Jan 26 16:38 n64
drwxrwsrw-+  2 root users 4096 Feb 28 21:39 nds
drwxrwsrw-+  3 root users 4096 Jan 24 17:55 nes
drwxrwsrw-+  3 root users 4096 Mar  5 10:28 ps1
drwxrwsrw-+  2 root users 4096 Feb 28 21:40 ps2
drwxrwsrw-+  2 root users 4096 Feb 28 21:40 ps3
drwxrwsrw-+  2 root users 4096 Mar  7 10:15 psp
drwxrwsrw-+  2 root users 4096 Feb 28 21:41 psvita
drwxrwsrw-+  3 root users 4096 Jan 24 18:21 snes
drwxrwsrw-+  3 root users 4096 Mar  4 01:15 switch
drwxrwsrw-+  2 root users 4096 Feb 28 21:42 wii
drwxrwsrw-+  2 root users 4096 Feb 28 21:42 wiiu
$ ls -la
total 44
drwxrwsrw-+  7 root users 4096 Mar  7 10:12 .
drwxr-xr-x   3 root root  4096 Dec 26 13:31 ..
drwxrwsrw-+  3 root users 4096 Mar  2 00:53 compose
drwxrwsrw-+  3 root users 4096 Mar  4 00:29 data
drwxrwsrw-+  3 root users 4096 Dec 30 02:11 media
drwxrwsr-x+  5 RomM RomM  4096 Mar  4 00:54 romm
drwxrwsrw-+ 13 root users 4096 Mar  6 00:58 roms

Display More

I see a potential issue here too. The roms directory and the contents are owned by root:users. The RomM user appears to belong to belong to the RomM and usesrs group, but the compose file is using PUID/PGID of 1004:1005 which is RomM:RomM, so the container is operating as RomM user and group nut the riles are root:users. There is not ownership and permissions overlap. It does look like your permissions are using r/w for others, so those permissions should work, but depending on the container/application design, the lack of user/group overlap can sometimes cause issues.

You would be better off either using a PGID of 100 in the compose file, or if you want more isolation, use a user/group for the docker user that is used for all dockers, but is not part of the normal users group as is often suggested in docker guides.

Quote from quote241

I just tried giving the container to PUID 100 and got the same errors. Also tried completely deleting the PUID and PGID variables (they're not present in the example compose and their docs never mention adding them) to no avail.

If the PUID/PGID is not listed in the documentation then it likely is not supported. Those are features that have to be enabled in the container build, and are not universal docker features.

Docker does support user directives, but they do not behave the same as the PUID/PGID in some containers. The PUID/PGID settings essentially tell the containers that support it to interact with the files that are out on the host OS as if they are that user, but inside the container the operations are done as whatever user the container was designed to run as. The docker user directive tries to change the container internals to that user and group to avoid permissions conflicts, but if the user and group are not defined in the container the container will not work correctly.

If a container does not support PUIS/PGID, then it will function on the host as root but files owned by root are not typically accessible by non-root users.

I am not running this container and I am not running mergerfs which adds a layer of complexity that not all containers can navigate.

Looking a bit closer at that compose file, it looks like it is designed to use docker volumes for it'd viles and not bind mounts to normal directories.

The compose file creates a romm_resources volume and the official compose file has the roms mtadata being stored in that volume, but you have instead used a bind mount to a host directory. While this is ok to do with most containers, I have encountered a few that will not work correctly with bind mounts.

I would suggest that you test with the container using the docker volume for rom metadata storage to see if it behaves better. This could be the part that is actually causing your problems.

Quote from quote241

Forgive me for not totally following. Are you saying I should change the resources path to something else? And if so, where?

Yes I am.

Here is the offical example compose files:

version: "3"

volumes:
    mysql_data:
    romm_resources:
    romm_redis_data:

services:
    romm:
        image: rommapp/romm:latest
        container_name: romm
        restart: unless-stopped
        environment:
            - DB_HOST=romm-db
            - DB_NAME=romm # Should match MARIADB_DATABASE in mariadb
            - DB_USER=romm-user # Should match MARIADB_USER in mariadb
            - DB_PASSWD= # Should match MARIADB_PASSWORD in mariadb
            - ROMM_AUTH_SECRET_KEY= # Generate a key with `openssl rand -hex 32`
            - SCREENSCRAPER_USER= # These are the recommended metadata providers
            - SCREENSCRAPER_PASSWORD= # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#screenscraper
            - RETROACHIEVEMENTS_API_KEY= # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#retroachievements
            - STEAMGRIDDB_API_KEY= # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#steamgriddb
            - HASHEOUS_API_ENABLED=true # https://docs.romm.app/latest/Getting-Started/Metadata-Providers/#hasheous
        volumes:
            - romm_resources:/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)
            - romm_redis_data:/redis-data # Cached data for background tasks
            - /path/to/library:/romm/library # Your game library. Check https://github.com/rommapp/romm?tab=readme-ov-file#folder-structure for more details.
            - /path/to/assets:/romm/assets # Uploaded saves, states, etc.
            - /path/to/config:/romm/config # Path where config.yml is stored
        ports:
            - 80:8080
        depends_on:
            romm-db:
                condition: service_healthy
                restart: true

    romm-db:
        image: mariadb:latest
        container_name: romm-db
        restart: unless-stopped
        environment:
            - MARIADB_ROOT_PASSWORD= # Use a unique, secure password
            - MARIADB_DATABASE=romm
            - MARIADB_USER=romm-user
            - MARIADB_PASSWORD=
        volumes:
            - mysql_data:/var/lib/mysql
        healthcheck:
            test: [CMD, healthcheck.sh, --connect, --innodb_initialized]
            start_period: 30s
            start_interval: 10s
            interval: 10s
            timeout: 5s
            retries: 5

just like yours, it declares a rom_resources volume which is intended to be used for that metadata stuff (the first line under the volumes section), but you have changed the rom_resources to be a bind mount of - /srv/mergerfs/BigPool/romm/resources:/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)

This change could be causing your problems.

Quote from quote241

- romm_resources:/srv/mergerfs/BigPool/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)

This is not right.

docker mappings are host on the left, container on the right, with a : in between. You never change the right side, only change the left.

The official version is:

- romm_resources:/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)

Your original was not using the declared volume:

- /srv/mergerfs/BigPool/romm/resources:/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)

You changed it to this where you are mapping the docker volume into a path inside the container that is really outside the container and not where the application is looking:

- romm_resources:/srv/mergerfs/BigPool/romm/resources # Resources fetched from IGDB (covers, screenshots, etc.)

The right is never changed as that is inside the container and where application is looking in there. The left gets mapped into the right side in the container.

You should have left it like the example compose file. The left is the docker volume, the right is the path inside the container.

Well as I said above, I don’t run the container and I don’t run mergerfs.

I can try to spin a container up when I get a chance, to see if I can replicate the problem, but if I can’t I would then tend to think it may be related the mergerfs pool which as I mentioned can cause some dockers to not work right.

Quote from quote241

Damn, if I'd known that going into this I wouldn't have set it up lol. Thank you for trying to help me out

No worries. I don’t mind trying to help and figure out a problem. Unfortunately sometimes it’s easier when you can see what is happening and how a container behaves first hand. I’ll try to have a look later tonight or tomorrow after work.

I was able to spin up a container and upload and download roms without a problem. I did not have the system use a pre-existing rom library, but instead allowed it to create it's own library structure and then uploaded to that and downloaded from it. It did not seem to work well if I didn't let it create it's expected folder structures, but I will concede that I am not familiar with the application and am not inclined to spend several hours or days figuring out exactly how it works.

That said, the fact that I could upload and download without any errors tells me that it works on a normal filesystem (I run xfs on a mdadm raid5). Your problems are most likely either a configuration issue stemming from a pre-existing library, an error created by the compose files problems we already went over that are now persistent in the database and may be causing problems, or the mergerfs issue.

I would suggest that you start again, by shutting it down and deleting the docker database volume, setting the library path on the left of the mappings to an empty directory, starting it up again letting the application create it's library structure in another directory and then try to upload and download to/from it. You may even need to delete the files in it's config directory and go completely fresh.

If you still have problems I would repeat the reset proces I just mentioned, but this time try to change all the host paths to a single drive instead of the mergerfs pool. If it works then, you know it's a problem with mergerfs

Quote from quote241

I'm just now reading this again and seeing t mentions of uploading and it reminded me of something. I can actually upload from the RomM web interface with no issues, downloading is the only issue. Could that mean anything specific?

It doesn't mean anything to me aside from the issues I already mentioned and recommending the reset.

Quote from quote241

Otherwise, I'm looking into switching over to RAID5 instead of snapraid + mergerfs; the other 2 solutions didn't solve the issue. I made a reddit post on the OMV sub and everyone is insistent on mergerfs not being the issue, but nobody seems to be able to narrow down what the issue may actually be. Guess RomM is too niche an app for right now, and I can't find any other page with anyone having the same issue. Super odd.

You can attempt to direct the mappings to just a single drive first. It can even be a directory on your OS drive for a quick test. This will bypass the mergerfs/snapraid configuration. That would be the only way to rule out or confirm if it is the mergerfs/snapraid config or if there is something else going on.