Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. OpenProject
  3. Frequent 500s because of permission denied /app/code/tmp/cache

Frequent 500s because of permission denied /app/code/tmp/cache

Scheduled Pinned Locked Moved Solved OpenProject
28 Posts 8 Posters 4.7k Views 8 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • nebulonN Offline
    nebulonN Offline
    nebulon
    Staff
    wrote on last edited by
    #15

    I have published a new app package with an attempt to fix the issue. Essentially all processes as well as apache2 only run as www-data so they don't have to drop privileges on their own. Especially phusion passenger for ruby gets loaded as root through apache, this is now fixed. Also all rake tasks are now run as www-data.

    Please let us know if this indeed fixes the issue or not. I was not able to reliably reproduce the issue.

    BenoitB 1 Reply Last reply
    1
    • nebulonN nebulon

      I have published a new app package with an attempt to fix the issue. Essentially all processes as well as apache2 only run as www-data so they don't have to drop privileges on their own. Especially phusion passenger for ruby gets loaded as root through apache, this is now fixed. Also all rake tasks are now run as www-data.

      Please let us know if this indeed fixes the issue or not. I was not able to reliably reproduce the issue.

      BenoitB Offline
      BenoitB Offline
      Benoit
      translator
      wrote on last edited by
      #16

      Hi @nebulon,
      i sent you an email because the last update of the openproject app doesn't work well. It can't restart after the update.
      Log file : "Jan 22 09:46:31 `/var/www` is not writable."
      Thanks for your help

      nebulonN 1 Reply Last reply
      0
      • BenoitB Benoit

        Hi @nebulon,
        i sent you an email because the last update of the openproject app doesn't work well. It can't restart after the update.
        Log file : "Jan 22 09:46:31 `/var/www` is not writable."
        Thanks for your help

        nebulonN Offline
        nebulonN Offline
        nebulon
        Staff
        wrote on last edited by
        #17

        @benoit ah only saw this now after answering your support mail. This is expected since bundler should not run as root and thus should not have access to /var/www. In fact that folder is not really being utilized. Bundler anyways falls back to /tmp.

        I didn't get the restart issue though, can you explain that one?

        BenoitB 1 Reply Last reply
        0
        • nebulonN nebulon

          @benoit ah only saw this now after answering your support mail. This is expected since bundler should not run as root and thus should not have access to /var/www. In fact that folder is not really being utilized. Bundler anyways falls back to /tmp.

          I didn't get the restart issue though, can you explain that one?

          BenoitB Offline
          BenoitB Offline
          Benoit
          translator
          wrote on last edited by
          #18

          @nebulon the app is running but we have this on the screen "This app is currently not responding. Try refreshing the page."
          This happened this night after app updated.

          1 Reply Last reply
          0
          • nebulonN Offline
            nebulonN Offline
            nebulon
            Staff
            wrote on last edited by
            #19

            Oh I see. Since I had access to your instance for fixing the issue anyways, I saw that the app was healthy and running, but the nginx reverse proxy config wasn't correctly updated.
            This may actually be a bug in Cloudron. The reason likely is that I've changed the app's internal port from 80 to 8000 to not require apache to run as root.

            To fix this quickly, I've just submitted the location form of the app configure, which triggers a recreation of the reverse proxy files.

            At least for me the app is now reachable.

            BenoitB BrutalBirdieB 2 Replies Last reply
            2
            • nebulonN nebulon

              Oh I see. Since I had access to your instance for fixing the issue anyways, I saw that the app was healthy and running, but the nginx reverse proxy config wasn't correctly updated.
              This may actually be a bug in Cloudron. The reason likely is that I've changed the app's internal port from 80 to 8000 to not require apache to run as root.

              To fix this quickly, I've just submitted the location form of the app configure, which triggers a recreation of the reverse proxy files.

              At least for me the app is now reachable.

              BenoitB Offline
              BenoitB Offline
              Benoit
              translator
              wrote on last edited by
              #20

              @nebulon yes it works now ! Great ! That it means this problem can occur on a new app install ? And what about a restart or restore of an openproject app ? Thanks

              nebulonN 1 Reply Last reply
              0
              • BenoitB Benoit

                @nebulon yes it works now ! Great ! That it means this problem can occur on a new app install ? And what about a restart or restore of an openproject app ? Thanks

                nebulonN Offline
                nebulonN Offline
                nebulon
                Staff
                wrote on last edited by
                #21

                @benoit this is only an issue once during that one update.

                1 Reply Last reply
                1
                • nebulonN Offline
                  nebulonN Offline
                  nebulon
                  Staff
                  wrote on last edited by
                  #22

                  So the was indeed a bug in the platform code with the port change. This is now fixed and will be part of the next Cloudron release.

                  1 Reply Last reply
                  1
                  • P Offline
                    P Offline
                    Peter Newman
                    wrote on last edited by
                    #23

                    Based on my diagnosis, this is caused by the "worker" scheduler/cron task. Every time that runs (based on the log), I see a new file in /app/code/tmp/cache owned by root. Sometimes this new file is in a new directory (as the cache splits the storage across multiple directories on demand based on the random file name). When this newly created root owned folder is used by the normal process (running as www-data), it fails the permission check and users see the error message.

                    I've been "fixing" this by manually running

                    /app/code/tmp/cache# find -user root -exec chown www-data:www-data {} \;
                    

                    at the terminal.

                    nebulonN 1 Reply Last reply
                    0
                    • P Peter Newman

                      Based on my diagnosis, this is caused by the "worker" scheduler/cron task. Every time that runs (based on the log), I see a new file in /app/code/tmp/cache owned by root. Sometimes this new file is in a new directory (as the cache splits the storage across multiple directories on demand based on the random file name). When this newly created root owned folder is used by the normal process (running as www-data), it fails the permission check and users see the error message.

                      I've been "fixing" this by manually running

                      /app/code/tmp/cache# find -user root -exec chown www-data:www-data {} \;
                      

                      at the terminal.

                      nebulonN Offline
                      nebulonN Offline
                      nebulon
                      Staff
                      wrote on last edited by
                      #24

                      @peter-newman ah great observation, I will release a new package with a fix then. I guess I can revert the apache and thus port change patch then.

                      BenoitB 1 Reply Last reply
                      0
                      • nebulonN nebulon

                        @peter-newman ah great observation, I will release a new package with a fix then. I guess I can revert the apache and thus port change patch then.

                        BenoitB Offline
                        BenoitB Offline
                        Benoit
                        translator
                        wrote on last edited by
                        #25

                        hi @nebulon, i don't know if it is due to your update but we encounter the not responding screen on openproject on an up to date and restarted server. I sent you an email.

                        nebulonN 1 Reply Last reply
                        0
                        • BenoitB Benoit

                          hi @nebulon, i don't know if it is due to your update but we encounter the not responding screen on openproject on an up to date and restarted server. I sent you an email.

                          nebulonN Offline
                          nebulonN Offline
                          nebulon
                          Staff
                          wrote on last edited by
                          #26

                          @benoit this is likely the same issue as after the other update, just recreate the nginx configs via submitting the domain/location settings without changing them in the app configure screen. This will be fixed with Cloudron 6.1

                          BenoitB 1 Reply Last reply
                          1
                          • nebulonN nebulon

                            @benoit this is likely the same issue as after the other update, just recreate the nginx configs via submitting the domain/location settings without changing them in the app configure screen. This will be fixed with Cloudron 6.1

                            BenoitB Offline
                            BenoitB Offline
                            Benoit
                            translator
                            wrote on last edited by
                            #27

                            @nebulon thanks for your explanation. it works now 🙂

                            1 Reply Last reply
                            0
                            • nebulonN nebulon

                              Oh I see. Since I had access to your instance for fixing the issue anyways, I saw that the app was healthy and running, but the nginx reverse proxy config wasn't correctly updated.
                              This may actually be a bug in Cloudron. The reason likely is that I've changed the app's internal port from 80 to 8000 to not require apache to run as root.

                              To fix this quickly, I've just submitted the location form of the app configure, which triggers a recreation of the reverse proxy files.

                              At least for me the app is now reachable.

                              BrutalBirdieB Offline
                              BrutalBirdieB Offline
                              BrutalBirdie
                              Partner
                              wrote on last edited by
                              #28

                              @nebulon said in Frequent 500s because of permission denied /app/code/tmp/cache:

                              Oh I see. Since I had access to your instance for fixing the issue anyways, I saw that the app was healthy and running, but the nginx reverse proxy config wasn't correctly updated.
                              This may actually be a bug in Cloudron. The reason likely is that I've changed the app's internal port from 80 to 8000 to not require apache to run as root.

                              To fix this quickly, I've just submitted the location form of the app configure, which triggers a recreation of the reverse proxy files.

                              At least for me the app is now reachable.

                              This explains a lot.

                              Like my work? Consider donating a drink. Cheers!

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • Bookmarks
                              • Search