My GitLab appliance on DigitalOcean finally ran out of space, so I attached a block storage volume,
I then updated the gitlab.rb lfs-storage path to the new location (mounted in /mnt/git01/lfs-storage), copied the old storage over, reconfigured and restarted. Out of necessity I also removed the old lfs-storage directory.
After this when trying to push LFS files GitLab has a write error. I also cannot pull LFS assets so it seems like it cannot read either.
I also tried reverting the path and mounting the lfs-storage volume in the original lfs-storage location (I believe it was /var/opt/lfs-storage) but this also did not work.
I created a new GitLab appliance instance on DigitalOcean and attached another block-storage volume and had the exact same results pushing an existing repo to it.
Please help! Is this a DigitalOcean or a GitLab problem? I desperately need the repo working again.
I randomly fixed it in the end, the solution was in the docs but not anywhere near anything specifically about LFS.
Steps to reproduce:
- Change any of the directory paths for gitlab to a mount point
Steps to fix:
- Get drunk
- Turn off directory management using “manage_storage_directories[‘enable’] = false” in the config file
- chmod -R 770 lfs-storage-directory
- chown -R git:root lfs-storage-directory
You definitely want this option on by default, but you need to turn it off the moment mount points get involved because gitlab constantly tries to “fix” directories and it can’t do that successfully across a mount point for some reason. even if they’re already adequately configured.
It would be super nice if gitlab managed ownership and perms but was able to test for the involvement of a mount point and replicate the behaviour of disabling directory management on that particular location as needed.
2 Likes
I know that it’s old thread, but maybe you do remember where in the docs this can be found?