Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-04T08:04:35.113Z
Answers: 2018-07-04T08:04:35.113Z
Answers: davidb
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2018-07-02T08:35:54.223Z
Comments: Mount the target system with uid and forceuid values, see mount.cifs manpage: https://linux.die.net/man/8/mount.cifs
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-07-02T13:08:24.543Z
Comments: 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.
Comments: davidb
Comments: CC BY-SA 4.0
Comments: 2018-07-02T13:20:08.003Z
Comments: Feel free to self answer, I wouldn't go into all needed options and theirs implications
Comments: Tensibai
Tags: <docker><containers>
Title: docker volumes on cifs share cause permission disaster
UserDisplayName: davidb
ThreadText: # 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
  
  ```
  
  
  ---
  
  