Sonarr & Radarr cause docker to become unresponsive when sending files to QNAP NAS [RESOLVED]

[bcherb2]

Occasionally when files are being moved by Sonarr or Radarr to their destination on the NAS, the docker will become completely unresponsive. I can’t stop or kill it, and even rebooting takes a very long time. IOWAIT CPU% jumps up to between 30-50% according to Netdata, and just remains steady for as long as I leave it running. The only fix I’ve found is to reboot, stop, delete, and trash all data/config (I think it’s likely the move tries to resume as soon as s/radadd boot up).

I’ve seen several users with similar problems, but no solutions yet. I’ve tried:

• Using older versions of each docker

• Updating system / Docker-ce / docker-compose / docker-compose.yml version

• Increasing mem, mem_swap, and shared container volume size for the affected dockers via docker-compose

• Restoring older versions of each database

Nothing works, always the same result. I’m at my wits end, anyone have any idea?
netdata chart

Hardware: Dell Inspiron laptop, QNAP 421 via ethernet
8gb memory, 512gb SSD, i7 CPU
OS: Ubuntu headless server 18.04
Docker/compose v: latest on all versions
Sonarr, radarr, jackett, netdata, watchtower, ombi, plexpy, transmission, plex

[j0nnymoe]

Could you post some snippets of your docker compose file?

So from reading your hardware section, would I be right in thinking the laptop is where the containers are running and the QNAP is mounted as smb/nfs shares?

[bcherb2]

Yes to your question. Containers are all on the SSD. Files download to the SSD then get moved by Sonarr/Radarr to the SMB share.

I found an issue on the Linuxserver.io github issues tracker that sounded very fimiliar that suggested turning off ‘OPLock’ on the NAS. I’ve turned that off and am giving it another go, problem usually takes 1-3 days to occur. I will report back if that was indeed the issue.

Here is my docker-compose segment:

    sonarr:
    image: linuxserver/sonarr
    container_name: sonarr
    restart: unless-stopped
    network_mode: 'bridge'
    ports:
        - '${IP_ADDRESS}:8989:8989'
    environment:
        - PUID=${PUID}
        - PGID=${PGID}
        - VIRTUAL_HOST=sonarr.${DOMAIN}
        - LETSENCRYPT_HOST=sonarr.${DOMAIN}
        - LETSENCRYPT_EMAIL=${EMAIL}
    volumes:
        - './sonarr:/config'
        - '/media/NAS/TV Shows:/TV'
        - '/etc/localtime:/etc/localtime:ro'
        - ${USERDIR}/Downloads/completed:/data/completed

[bcherb2]

I’ve tried putting both dockers under as much stress as possible the past 24 hours and not a single problem yet.

The problem seemed to be SMB OPLOCK was turned on via the fileserver and mono was crashing when trying to transfer a file that was/became locked.

We can close this issue now, Thanks!

[homer]

Interesting fix! Glad you got it sorted - hopefully this helps somebody else in the future