Running Gitlab CE from the Docker image saving data onto NFS share, ACL problems

I’m following this README: to the letter except that my /srv/gitlab folder isn’t a local filesystem but a mounted NFS share which resides on a Synology NAS.

The NAS doesn’t have many options for NFS, I opted to have UNIX ACLs as default (instead of WIN) and gave the IP which runs my docker container full access.

So starting a new gitlab CE container results in this error message in its logs and the container keeps looping and never properly starts.

{"log":"\u001b[0mSTDERR: /opt/gitlab/embedded/lib/ruby/2.3.0/logger.rb:703:in `initialize': 
Permission denied @ rb_sysopen - /var/log/gitlab/gitlab-shell/gitlab-shell.log 

I then found this section fo the README on how to fix Linux ACLs: except that it doesn’t work. I run Debian Jessie and using the commands shown this is what I get:

getfacl /srv/gitlab/
getfacl: Removing leading '/' from absolute path names
# file: srv/gitlab/
# owner: root
# group: docker

setfacl -mR default:group:docker:rwx /srv/gitlab/
setfacl: Option -m: Invalid argument near character 1

I’ve been reading up on setfacl for a couple of hours now but am getting nowhere. can someone help? This is definitely a ACL issue as the container starts just fine when NOT using an NFS share.


I found this doc about gitlab NFS compatibility:

which states:

File locking: GitLab requires advisory file locking, which is only supported natively in NFS version 4. NFSv3 also supports locking as long as Linux Kernel 2.6.5+ is used. We recommend using version 4 and do not specifically test NFSv3.

I am not using NFS v4 on my Synology NAS but it can be enabled. I will try this and report back whether it fixes the issue.

That same doc also has more advice regarding no_root_squash and sync, both option sare already in use on my setup.

It still doesn’t work, same problem as in my initial thread even though I now have sync=on as well as no_root_squash and using nfs4

Also the example given here:

NFS Client mount options
Below is an example of an NFS mount point defined in /etc/fstab we use on /var/opt/gitlab/git-data nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nobootwait,lookupcache=positive 0 2

kept giving me “unknown mount option” until I removed “nobootwait” then it successfully mounted my nfs share using v4

Any more ideas?

same advice here:

they say to use no_root_squash

OK, gave up on NFS shares and tried a SAMBA share. I mounted the folder Gitlab-New with active directory user credentials into /mnt/gitlab

Looks all great so far and then I start a gitlab-latest docker container pointing it to this directory:

docker run --detach \
    --hostname \
    --publish 30443:443 --publish 3080:80 --publish 3022:22 \
    --name gitlab \
    --restart unless-stopped \
    --volume /mnt/gitlab/config:/etc/gitlab \
    --volume /mnt/gitlab/logs:/var/log/gitlab \
    --volume /mnt/gitlab/data:/var/opt/gitlab \

and that immediately triggers permission problems the likes of:
e[31mError executing action create on resource 'directory[/etc/gitlab]'e[0m

Permission denied @ chown_internal - /etc/gitlabe[0m

e[0mCookbook Trace:e[0m
/opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:33:in `from_file'e[0m

e[31mError executing action `create` on resource 'directory[/etc/gitlab]'e[0m

Permission denied @ chown_internal - /etc/gitlabe[0m

e[0mCookbook Trace:e[0m

/opt/gitlab/embedded/bin/runsvdir-start: line 37: /proc/sys/fs/file-max: Read-only file system

Has anyone gotten the Gitlab Docker container up and running on any kind of share?

Having the same problem. I tried all of your attempted fixes except Samba with the same results.

@jdmarble sorry to hear but on the other hand I’m glad I’m not the only one with this issue. Please let me know if you figure out any kind of solution to this.

guys and gals (@ovizii, @jdmarble), the same issues still exists even 1.5 years later.
NFS gives permission problems
Have you found any solutions to this?
If not, what does your alternative solution looks like?
Kind regards :slight_smile:

Nope, sorry. Our solution was to give up and move to Gogs :-/