<p>The problem can be solved by using mount options that force the application of the correct user and group eventhough these attributes can't really be set on the target system its sufficient to get around the docker related problem. </p>

<p>Also a reasonable set of privileges needs to be defined that is used for new files and folders.</p>

<pre><code>mount -t cifs -o username=user,password=pass, \               # provide creds
  uid=www-data,forceuid,gid=root,forcegid, \                  # force gid and uid
  file_mode=744,dir_mode=744 //host/share /local/mountpoint   # set permissions for new files and directories
</code></pre>

CC BY-SA 4.0
2018-07-04T08:04:35.113Z
2018-07-04T08:04:35.113Z
davidb
<p>I have a small vm running docker it only has a 20gig SSD which is more than enough for the OS + SWAP + Docker and the container images. But now I want to run a nextcloud docker image on that host. Because of the lack of space I mounted a cifs share to /data and started docker linking nextclouds data directory to the share.</p>

<pre><code> docker run -v /data/docker-volumes/nextcloud/data/:/var/www/html/ -p 8080:80 nextcloud
</code></pre>

<p>The files are created but then docker tries to change the ownership of the files to www-data which does not work because the user www-data does not exist on the target system (the SMB Server). Which fails and terminates the docker instance.</p>

<pre><code>rsync: chown "/var/www/html/data" failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]
</code></pre>

<p>There is no way to create the user www-data on the target system. Is there any way to get around this?</p>

CC BY-SA 4.0
2018-07-02T08:35:54.223Z
Mount the target system with uid and forceuid values, see mount.cifs manpage: https://linux.die.net/man/8/mount.cifs
Tensibai
CC BY-SA 4.0
2018-07-02T13:08:24.543Z
Thank you very much! It helped solving the problem eventhough I ended up with a much longer list of necessary options. Please reply to my question though I can mark it as correct.
davidb
CC BY-SA 4.0
2018-07-02T13:20:08.003Z
Feel free to self answer, I wouldn't go into all needed options and theirs implications
Tensibai
<docker><containers>
docker volumes on cifs share cause permission disaster
davidb
# docker volumes on cifs share cause permission disaster

(Asked by: username_0 on 2018-07-02)

I have a small vm running docker it only has a 20gig SSD which is more than enough for the OS + SWAP + Docker and the container images. But now I want to run a nextcloud docker image on that host. Because of the lack of space I mounted a cifs share to /data and started docker linking nextclouds data directory to the share.
 docker run -v /data/docker-volumes/nextcloud/data/:/var/www/html/ -p 8080:80 nextcloud

The files are created but then docker tries to change the ownership of the files to www-data which does not work because the user www-data does not exist on the target system (the SMB Server). Which fails and terminates the docker instance.
rsync: chown "/var/www/html/data" failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]

There is no way to create the user www-data on the target system. Is there any way to get around this?

**Tags:** docker, containers

> **Comments:**
> **username_1**: Mount the target system with uid and forceuid values, see mount.cifs manpage: https://linux.die.net/man/8/mount.cifs  
> **username_0**: Thank you very much! It helped solving the problem eventhough I ended up with a much longer list of necessary options. Please reply to my question though I can mark it as correct.  
> **username_1**: Feel free to self answer, I wouldn't go into all needed options and theirs implications  

---

## 1 answers

### Answer by username_0 on 2018-07-04. Score: 4 | Accepted answer

The problem can be solved by using mount options that force the application of the correct user and group eventhough these attributes can't really be set on the target system its sufficient to get around the docker related problem. 
Also a reasonable set of privileges needs to be defined that is used for new files and folders.
mount -t cifs -o username=user,password=pass, \               # provide creds
  uid=www-data,forceuid,gid=root,forcegid, \                  # force gid and uid
  file_mode=744,dir_mode=744 //host/share /local/mountpoint   # set permissions for new files and directories


---

