Change:
fileMode        = "file_mode" dirMode         = "dir_mode" vers            = "vers" <del> defaultFileMode = "0700" defaultDirMode  = "0700" </del> <ins> defaultFileMode = "0755" defaultDirMode  = "0755" </ins> defaultVers     = "3.0" )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Using azureFile volume after 1.8.x mount the share onto host with both dirmode and filemode options set to 0700, which was changed in this commit. This disallow any container run with non root user (which is the suggested way to run app) to access the contents. What you expected to happen: The mode should at least set to 755 or even 777, which seem to be fine since we can still configure of volume or of volumeMount. How to reproduce it (as minimally and precisely as possible): Use azureFile at 1.8.x up versions. Anything else we need to know?: might solve this too, but closed :( Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-24T21:07:53Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-24T19:38:10Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Bare metal on Azure VM OS (e.g. from /etc/os-release): Ubuntu 16.04.2 Kernel (e.g. ): Linux -Ubuntu SMP Tue Aug 8 11:56:56 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others:
/sig azure
/assign
I would like to set the mode as 777, let me know your concern about this, thx.
Should any user from the container have full access by default to the volume? I think is a bit too permissive. The default value could be concisely overwritten by the when the permissions are too strict. Also the option is set by default to false if not specified. In general, I would go by default with , and provide the option to increase the privileges when required.

does storage class support mountOptions in v1.8? From the doc: it's already supported, but I never make it work for azure disk and azure file, below is my config:
apparently no :) Need to get mount options by calling MountOptionFromSpec and join to PV options
while for azure file, it's already joining: point is it says invalid for my azure file config:
sorry, correct format should be like this, azure file is provisioned successfully:
so currently azure file/disk does not support mountMounts, I would create a task to support it, seems like it's only a little code change. :)
I have a for this, use mount options in storage class, below is an example:
IT's a real show-stopper using Azurefile! Like any rails app using non-root uid will not be able to Access root-only mounts (like phusion / passenger). I hope this get's fixed soon to add fsgroup properly! It's also very weird that also chown within container is not able to Change ownership of an azure file cifs mount Point!
Hi fsgroup could be set by k8s security context, is that what you want?
Thanks for the hint, but this ist not working for azurefiles Volume, because it's not a usual PVC and a dedicated Volume mount Parameter, without the possibility of fsgroup and fsuid. Would be trivial to fix, because it's a regular cifs 3.0 mount in the Background... I was absolutely surprised that this ist still not fixed in the Go File for the azurefile class in Kubernetes...
you can set uid, gid in mountOptions, the code is already in v1.9.0, you can set filemode and dirmode in mountOptions too, see below example:
Thanks a lot. I the storage class with my uid/gid, but this storage class is not used.. volumes: name: azure azureFile:
I have cherry-pick this mountOptions feature to v1.8, see: Seems you are using azure file static provisioning, here is an example: BTW, set the dirmode & filemode as 0700 is really too strict, customers complain this a lot. I am planing to change it, which value would you suggest? ? Thanks.
AWESOME, working perfectly now!! I really appreciate your immediate Feedback.

I owe you a beer, next time you visit Germany (Hamburg) ! :-) I'd the challenge to set set uid & guid to 0777 to my share that the rails app was working properly, which I've to figure out. I'd recommend to go with 0744 as Default Settings! GREAT COMMUNITY SUPPORT, thanks a lot!! Rgds, Gerald aka Kontainerschiff
I am happy that it works on your side. Your encourage would be my power!! Germany is in my traveling list :-)
Same problem here, still get dirmode=0700 and filemode0700 when using K8s storage class with azure file. When inspecting the PV I see that the storage class has passed the correct mountOptions that are dirmode=0777 and filemode=0777, but when the volume is mounted, it's being mounted with dirmode=0700 and filemode0700. - Cloud provider Service
Hi , I just did a check, PR has already into v1.8, while it's not in v1.8.3 or v1.8.4, it is in v1.8.5 definitely
and in v1.8.3, azure file code would ignore mountOptions in strorage class, mountOptions would be really used from v1.8.5
Thanks for the info, that's good to know so that I can skip using Azure file plugin for now.
It#s really a mess. I just upgraded to 1.8.4 and file_mode only mounts 0700 instead of necessary 0777. I'm on Azure Container Services,so now 1.8.5 upgrade possibility :-(
I'm in production in 1.8.4 and have to switch is a nightmare...
BTW: 1.8.2 was working !
1.8.2 is working? I have checked the code, it's still using 0700, If you are using v1.8.x, I would suggest you to use v1.8.5, it would support mountOptions. 0700 is really too restrict, I have created a to set as 0755.
well..1.8.5 still not available for ACS-engine ...therefore no upgrade on my cluster.

I'm using azureFile in my deployment yaml, but it does not have symbolic link support. I've read that I need to include "mfsymlinks" in my CIFS mount command.. sudo mount -t cifs //<your-storage-acc-<storage-file-share-name/media/shared -o vers=3.0,username=<storage-account-name,password='<storage-account-key',dirmode=0777,filemode=0777,mfsymlinks so how would I define this under mountOptions? Or ???
for dyanmic provisioning, using: for static provisioning, using: mount options support of azure file is available from v1.8.5
thanks andyzhangx! that did it.
hi guys, I am thinking add as default mountoptions into azurefile mount, thus to support symbolic link in azurefile mount, let me know your thoughts, thx
PTAL ^^
Andy, I am using static provisioning where I am providing the volume information to the pod (actually deployment to be exact) like the following: I am not using persistent volume or persistent volume claim as it seems to be required for dynamic provisioning only. I do have an issue where my program can read successfully from the Azure file mount but cannot write to it. What do you suggest I need to do to fix this? I tried using Azure AKS 1.9.2 and Azure AKS 1.9.6 clusters.
looks like I need to document this somewhere, you still need to use PV/PVC to set mountOptions:
Thank you Andy, it worked. If you look at the documentation here, unfortunately, it doesn't talk about it here:
would you add the above doc? Thanks.
Hi, I was wondering, what does this size mean in kubernetes? I created a 5TB file share on Azure, should this need to match and it should be 5TB or 5Ti?
if you are using PVC/PV matching, storage size is only for matching in PVC bounding process, the actual size could be different than ; while if you use dynamic provision of azure file, k8s will create a 5TB file share for you.

,Hi andy,I come from AKS documents.I have a question like .please see the below configuration If I have set up an azure file share which quota is 1G on azure storage service,how much capacity should I specify in the PV defination or storage in PVC.I am confusing about the actual size of mount data. there are three size. real size(quota) in azure file share in PV in PVC please help me understand.
the size in three configs should be identical. If you bring your own file share, k8s won't check if size in 2 or 3 is not identical to in 1. To make your config more simple, it's better make them identical.