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. Support
  3. File and Folder Ownership in /yellowtent/boxdata

File and Folder Ownership in /yellowtent/boxdata

Scheduled Pinned Locked Moved Solved Support
6 Posts 2 Posters 827 Views 2 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.
  • M Offline
    M Offline
    michaelpope
    wrote on last edited by
    #1

    Hey, can anybody confirm for me if all files in /yellowtent/boxdata should have an owner and group id of 998?

    Reason I'm asking is because on restore, some of my mail ended up as 1000, and I think it's preventing a proper backup, but I'm not 100% sure on that.

    Thanks.

    1 Reply Last reply
    0
    • girishG Offline
      girishG Offline
      girish
      Staff
      wrote on last edited by
      #2

      I wouldn't pay much attention to permissions because the user ids on the host system and ids on the containers don't always match.

      1000 is the id of the cloudron user inside all our containers. As for 998, this is probably user id of the yellowtent user. It could also happen if you copied files from another disk . In that case, 998 was probably the uid of your old linux system.

      What's the exact backup error? Usually, when the containers restart, they fix the permissions of the files...

      M 1 Reply Last reply
      2
      • girishG girish

        I wouldn't pay much attention to permissions because the user ids on the host system and ids on the containers don't always match.

        1000 is the id of the cloudron user inside all our containers. As for 998, this is probably user id of the yellowtent user. It could also happen if you copied files from another disk . In that case, 998 was probably the uid of your old linux system.

        What's the exact backup error? Usually, when the containers restart, they fix the permissions of the files...

        M Offline
        M Offline
        michaelpope
        wrote on last edited by michaelpope
        #3

        @girish That's the weird part. There wasn't an error, just an incomplete backup. Let me retry it and see if I can get it to happen again.

        I think I might have figured it out. This Log line:

        box:backuptask checkPreconditions: total required =551342991586 available=undefined
        

        I don't think it's supposed to be undefined. I'm going to have to wait a bit to do any fixes though.

        girishG 1 Reply Last reply
        0
        • M michaelpope

          @girish That's the weird part. There wasn't an error, just an incomplete backup. Let me retry it and see if I can get it to happen again.

          I think I might have figured it out. This Log line:

          box:backuptask checkPreconditions: total required =551342991586 available=undefined
          

          I don't think it's supposed to be undefined. I'm going to have to wait a bit to do any fixes though.

          girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by
          #4

          @michaelpope because of all this permissions mess, cloudron runs the backup "uploader" part (i.e the part that reads the files and creates a tarball or equivalent) as root user (via a sudo script to limit permissions). So, just to help to debug this further, it's most likely not related to permissions.

          That undefined doesn't look correct indeed. We parse the output of du -Dsb <backup_file_path> . Can you check if that output is correct ? Could it be it has some incorrect locale?

          M 1 Reply Last reply
          1
          • girishG girish

            @michaelpope because of all this permissions mess, cloudron runs the backup "uploader" part (i.e the part that reads the files and creates a tarball or equivalent) as root user (via a sudo script to limit permissions). So, just to help to debug this further, it's most likely not related to permissions.

            That undefined doesn't look correct indeed. We parse the output of du -Dsb <backup_file_path> . Can you check if that output is correct ? Could it be it has some incorrect locale?

            M Offline
            M Offline
            michaelpope
            wrote on last edited by michaelpope
            #5

            @girish I don't think so... locale seems correct. But it is reporting a very small amount.

            1109207166      /email_backup
            

            (which would be around 1 GB... which seems small enough).

            I wonder if the backup disk is having issues...

            I'll work on this a bit more and get back to you.

            EDIT: It turns out it was undefined because that was the 'source' folder, not the 'destination' folder.

            1 Reply Last reply
            0
            • M Offline
              M Offline
              michaelpope
              wrote on last edited by michaelpope
              #6

              Okay, I figured out what my problem was.

              I had some failed backups from yesterday, when I tried to get hardlinking working (and I also had a permission issue with the MySQL dump). As of such, I cleared the backup disk manually, and then triggered a backup cleanup in the Cloudron UI. Then I tried to back up again, however, I believe that Cloudron keeps an index of files it has already backed up to keep things speedy (which is nice). As of such, even though the other files no longer existed, it was only backing up the changes.

              To solve it, I just changed the backup method to a different method, and then changed it back again, which cleared the index.

              Thanks for all your help on this :).

              1 Reply Last reply
              2
              • girishG girish marked this topic as a question on
              • girishG girish has marked this topic as solved on
              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