Bootsnap::CompileCache::PermissionError

support
#1

Hello, everyone. I have fresh installment of Discourse in Docker.
So the problem is that after container rebuild, container is up and I can access app page. However, I get 502 as response. In logs or when I try accessing i.e. rails c (inside container) all I can see is this error:
`permission_error’: bootsnap doesn’t have permission to write cache entries in ‘tmp/cache/bootsnap/compile-cache’ (or, less likely, doesn’t have permission to read ‘/usr/local/lib/ruby/2.7.0/set.rb’) (Bootsnap::CompileCache::PermissionError)

In order to fix this I have to chown -R discourse:discourse /var/www/discourse/tmp (to be exact, it’s /var/www/discourse/tmp/cache/bootsnap) directory inside container, and right after app works fine even without restart. It’s quite obnoxious thing to do manually after each rebuild.

I was thinking that I can tackle it using custom commands section in app.yml with mentione above chown -R discourse:discourse /var/www/discourse/tmp, but unfortunately it doesn’t work. Commands seem to be called there (tried mkdir just to check), but file permissions are not affected.

What can be the issue here and how it can be resolved? Maybe there is some way to correctly change file permissions?

1 Like
#2

That’s odd. Did you follow Discourse official Standard Installation?

1 Like
#3

Of course. No additional steps were made.

1 Like
#4

Can you paste your container.yml file (sans passwords) ?

#5

Sure. Here you are:

## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
  - "80:80"   # http
  - "443:443" # https

params:
  db_default_text_search_config: "pg_catalog.english"

  ## Set db_shared_buffers to a max of 25% of the total memory.
  ## will be set automatically by bootstrap based on detected RAM, or you can override
  #db_shared_buffers: "256MB"

  ## can improve sorting performance, but adds memory usage per-connection
  #db_work_mem: "40MB"

  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8
  # DISCOURSE_DEFAULT_LOCALE: en

  ## How many concurrent web requests are supported? Depends on memory and CPU cores.
  ## will be set automatically by bootstrap based on detected CPUs, or you can override
  #UNICORN_WORKERS: 3

  ## TODO: The domain name this Discourse instance will respond to
  ## Required. Discourse will not work with a bare IP number.
  DISCOURSE_HOSTNAME: 'example.com'

  ## Uncomment if you want the container to be started with the same
  ## hostname (-h option) as specified above (default "$hostname-$config")
  #DOCKER_USE_HOSTNAME: true

  ## TODO: List of comma delimited emails that will be made admin and developer
  ## on initial signup example 'user1@example.com,user2@example.com'
  DISCOURSE_DEVELOPER_EMAILS: 'test@mail.com'

  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  # SMTP ADDRESS, username, and password are required
  # WARNING the char '#' in SMTP password can cause problems!
  DISCOURSE_SMTP_ADDRESS: smtp.mail.io
  #DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: 111
  DISCOURSE_SMTP_PASSWORD: 111
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)
  #DISCOURSE_SMTP_DOMAIN: discourse.example.com    # (required by some providers)
  #DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com    # (address to send notifications from)

  ## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
  #LETSENCRYPT_ACCOUNT_EMAIL: me@example.com

  ## The http or https CDN address for this Discourse instance (configured to pull)
  ## see https://meta.discourse.org/t/14857 for details
  #DISCOURSE_CDN_URL: https://discourse-cdn.example.com
  
  ## The maxmind geolocation IP address key for IP address lookup
  ## see https://meta.discourse.org/t/-/137387/23 for details
  #DISCOURSE_MAXMIND_LICENSE_KEY: 1234567890123456

## The Docker container is stateless; all data is stored in /shared
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git

## Any custom commands to run after building
run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  #- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
  #- exec: chown -R discourse:discourse /var/www/discourse/tmp/cache/bootsnap  # example command on how I'd tried to fix file permissions
  - exec: echo "End of custom commands"
#6

You didn’t run discourse-setup, right? It should have defined some things that you have commented out. I just made those changes and want to be sure that it’s working as expected.

Is there a reason you’re not using let’s encrypt?

I don’t see an explanation for your problem, though.

#7

Firstly, application was built using discourse-setup. After few tries of rebuilding it and seeing no positive result, I moved to one of pre-defined .yml configs from /samples directory, and then simply edited out it with my credentials.
Why not Let’s encrypt - asked to use client’s certificates. But as far as I understand - certificates have nothing to do with it, as they’re valid and there is no issue from it.
The issue seems to be on project level, which is specifically related to bootsnap cache file permissions (maybe the issue is on the side of Bootsnap).

#8

Thanks. I agree that’s not likely to be the problem. I did a couple of installs yesterday that worked just fine. I don’t see any explanation for your problem.

1 Like
#9

We were facing the same problem and I confirm that running (inside the docker container):

chown -R discourse:discourse /var/www/discourse/tmp

Fixed the problem! No restarts were required. The ‘tmp’ directory permissions were assigned to ‘discourse:www-data’ before the owner change. Hope this is something that in the future could be fixed so that this manual action won’t be needed after each rebuild.

1 Like
#10

Are you running launcher as root?

1 Like
#11

Yes @pfaffman, I am. Is that the problem?

#12

I don’t think so. I’m always starting my self-hosted instances as root and have never seen a problem like that.

Who’s the owner of the directory if you don’t use chown? In a recently rebuilt container it looks like this:

# ls -l /var/www/discourse/tmp
total 36
lrwxrwxrwx 1 root      root         19 Mar  2 14:56 backups -> /shared/tmp/backups
drwxr-xr-x 1 discourse discourse  4096 Mar  2 14:57 cache
drwxr-xr-x 1 discourse discourse  4096 Mar  2 14:57 ember-rails
drwxr-xr-x 1 discourse root       4096 Mar  2 15:04 pids
lrwxrwxrwx 1 root      root         20 Mar  2 14:56 restores -> /shared/tmp/restores
drwxr-xr-x 2 discourse root       4096 Mar  2 14:56 sockets
drwxr-xr-x 2 discourse discourse 12288 Mar  2 15:02 stylesheet-cache

Did you add any custom commands or hooks to your app.yml besides cloning plugins?

3 Likes
#13

The owner user and group of the /var/www/discourse/tmp directory was discourse:www-data after launching the container. Reassigning to discourse:discourse solved the issue. This had not happened to me before and I’ve been using discourse for several months already. Anyway, it was an easy fix and might have been random, so I don’t want to bother you with it anymore. Thanks a lot @gerhard!

2 Likes