Create backup on Windows share directory fails

How to Use GitLab
1

I have set up a GitLab server on Ubuntu 14.04 and want to copy backups to a different place. Since this is a Windows network and the Ubuntu box is only a virtual machine, I have to mount a Windows share directory to put the backups to. This is done using an smbcredentials file and an fstab entry. This works well, I can create, read, edit and delete files and directories in there as user or as root.

Then I’ve changed the GitLab config file according to the documentation and set the following item:

gitlab_rails[‘backup_path’] = “/mnt/backup”

When I start a new backup now, I get this error output:

user@db-gitlab:~$ sudo gitlab-rake gitlab:backup:create --trace
** Invoke gitlab:backup:create (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute gitlab:backup:create
** Invoke gitlab:backup:db:create (first_time)
** Invoke environment
** Execute gitlab:backup:db:create
Dumping database ...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /mnt/backup/db
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:250:in `mkdir'
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:250:in `fu_mkdir'
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:224:in `block (2 levels) in mkdir_p'
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:222:in `reverse_each'
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:222:in `block in mkdir_p'
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:208:in `each'
/opt/gitlab/embedded/lib/ruby/2.1.0/fileutils.rb:208:in `mkdir_p'
/opt/gitlab/embedded/service/gitlab-rails/lib/backup/database.rb:10:in `initialize'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:55:in `new'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:55:in `block (4 levels) in <top (required)>'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/opt/gitlab/embedded/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:11:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/opt/gitlab/embedded/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/rake-10.4.2/bin/rake:33:in `<top (required)>'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/bin/rake:23:in `load'
/opt/gitlab/embedded/service/gem/ruby/2.1.0/bin/rake:23:in `<main>'
Tasks: TOP => gitlab:backup:db:create

I can’t understand what the problem is. It fails to create the directory “db” but when I do from the prompt, it works just fine. What’s the problem with using a mounted Windows share for a backup?

2

Did you ever find a solution to this? I’m struggling with the same problem although I’m using the GitLab Docker container instead of a VM. I can even login to the Docker container and use the “gitlab” user account to write files to the mounted Windows share. So why would this backup script fail due to a permissions issue? Really strange.

3

No, I don’t use that. I let GitLab create backup archives locally and sync them to the network share with some other tool, don’t know which one ATM, maybe rsync or some kind of cp.

4

OK thanks, I’ll try that instead.

5

Hello. I have the exact same issue.
Any news regarding if/how you fixed this?

6

@LordMilutin He said how he did it, quoted below:

Directly attempting to mount the backup directory to smb doesn’t work because of permissions and this is why it fails. Permissions cannot be granted in the same way on an smb partition like it can with Linux directories.