Hi @jonathandey!

Try clearing your cache within the container by running docker-compose exec october artisan cache:clear

After that, can you tell me what triggers the error?

I've stumbled on permission issues within the cache before. It typically occurs when I'm not paying attention to the user running artisan commands or I've upset permissions within a mounted volume.

After reviewing your compose file, I should point out composer is available within the aspendigital/octobercms image. Setting INIT_PLUGINS=true will run composer within the container on plugin folders that have a composer.json file and no vendor folder. See the entry options.

Thanks @petehalverson,

I tried clearing the cache but got the same result.

I’ll try removing the extra composer dependency and use INIT_PLUGINS as you suggested.

Still no luck, unfortunately.

My docker-compose.yml file now looks like this

version: '2.2'

services:
  october:
    image: aspendigital/octobercms:latest
    volumes:
      - ./plugins/rainlab/user:/var/www/html/plugins/rainlab/user
      # - ./db/database.sqlite:/var/www/html/storage/database.sqlite
      - ./:/var/www/html/plugins/jd/dingoapi
    ports:
      - 9090:80
    environment:
       - INIT_OCTOBER=true
       - INIT_PLUGINS=true
       - APP_DEBUG=true
       - PHP_DISPLAY_ERRORS=true
       - API_PREFIX=api
       - API_DEBUG=true
       - JWT_TTL=31622400
       - JWT_BLACKLIST_ENABLED=false
       - API_DEFAULT_FORMAT=json

I made sure to delete the container before trying again, even going as far as to delete the image aspendigital/octobercms:latest so that it is re-pulled. I have also tried clearing the cache using

docker-compose exec october artisan cache:clear
docker-compose exec october artisan view:clear
docker-compose exec october artisan config:clear

Something to note though. It always appears to be the same cache value that is failed to write: /var/www/html/storage/framework/cache/11/de/11de31e1eabb2682cf62ee9c9ccb0630f1019006

I had a scheduled job that was creating a cache directory. Since cron is executed as root, the permissions on the created directory did not allow writes for www-data.

Maybe this could be the issue here as well.

I wonder if it is generally better to register the cron job for the www-data user instead of root.

# Remove from root
RUN crontab -u root -r
# Add to www-data
RUN crontab -u www-data /etc/cron.d/october-cron