A quote for mount.cifs man: "The core CIFS protocol does not provide unix ownership information or mode for files and directories. Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect."
Mounting with default uid,gid (which is 0:0 since the root is mounting) # mount -t cifs //ACCOUNT.file.core.windows.net/vol3 /mnt/test/ -o vers=3.0,\ user=ACCOUNT,\ password=PASSWORD,\ dir_mode=0777,\ file_mode=0777 # touch /mnt/test/FILE # stat /mnt/test/FILE File: ‘test/FILE’ Size: 0 Blocks: 0 IO Block: 16384 regular empty file Device: 25h/37d Inode: 9223407221226864640 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:cifs_t:s0 Access: 2016-04-04 16:47:44.867256100 +0000 Modify: 2016-04-04 16:47:44.867256100 +0000 Change: 2016-04-04 16:47:44.867256100 +0000 Birth: - Mounting with a given uid,gid: # mount -t cifs //ACCOUNT.file.core.windows.net/vol3 /mnt/test/ -o vers=3.0,\ user=ACCOUNT,\ password=PASSWORD,\ dir_mode=0777,\ file_mode=0777, uid=100003, gid= 100003 # stat /mnt/test/FILE File: ‘/mnt/test/FILE’ Size: 0 Blocks: 0 IO Block: 16384 regular empty file Device: 25h/37d Inode: 9223407221226864640 Links: 1 Access: (0777/-rwxrwxrwx) Uid: (100003/ UNKNOWN) Gid: (100003/ UNKNOWN) Context: system_u:object_r:cifs_t:s0 Access: 2016-04-04 16:47:44.867256100 +0000 Modify: 2016-04-04 16:47:44.867256100 +0000 Change: 2016-04-04 16:47:44.867256100 +0000 Birth: - Answering your question, yes we can change the uid,gid of a mount point. And yes, all files will have it's ownership changed. 2016-04-04 12:50 GMT-03:00 Paul Morie <[email protected]>: > We actually chatted about this last week in mountain view. One question I > have is: > > Say that I mount an azure volume with some args uid=x, gid=y. If I > remount the same volume later, can I change to x2,y2? As far as I know, > these mount options are basically a view setting -- they affect how azure > presents the mounted volume, and nothing else, so it seems like it should > be possible to change the mount options on a remount. > > Does anyone know the answer to that off the top of their head? > > P > > On Mon, Apr 4, 2016 at 11:30 AM, Clayton Coleman <[email protected]> > wrote: > >> I would expect the Azure volume to *do the right thing* with respect >> to setting UID/GID (since it can't be changed, and realistic apps >> expect it to be certain values, then those apps can't run on azure >> unless the plugin can solve the problem). Parameterizing the UID/GID >> may not be the right path, it might be something the security setup >> should decide. >> >> On Mon, Apr 4, 2016 at 11:18 AM, Diego Spinola Castro >> <[email protected]> wrote: >> > Ccing the list >> > >> > Em 4 de abr de 2016 12:02 PM, "Diego Spinola Castro" >> > <[email protected]> escreveu: >> >> >> >> Sorry, you are right, files can't get other ownership than default >> >> (uid,gid) underneath the mount point. >> >> As the root is mounting, so it owns the files, pods can write because >> >> file_mode and dir_mode are 0777 >> >> >> >> 2016-04-04 11:45 GMT-03:00 Clayton Coleman <[email protected]>: >> >>> >> >>> At the mount point, or anywhere underneath the mount point? >> >>> >> >>> On Mon, Apr 4, 2016 at 9:39 AM, Diego Spinola Castro >> >>> <[email protected]> wrote: >> >>> > Azure file plugin doesn't support Unix Permissions, so a pod can't >> >>> > manage >> >>> > file ownership at a mountpoint. This is a issue for PostgreSQL >> images, >> >>> > which >> >>> > complains if don't own the files. One alternative is to pass >> UID,GUID >> >>> > parameters at the mount, ex: >> >>> > >> >>> > mount -t cifs //ENDPOINT /MOUNTPOINT \ >> >>> > -o vers=3.0,user=USER,password=PASS,\ >> >>> > UID=<pod_user>,\ >> >>> > gid=<pod_supplemental_group>,\ >> >>> > dir_mode=0777,\ >> >>> > file_mode=0777 >> >>> > >> >>> > Is possible to have this or a similar solution ? >> >>> > >> >>> > >> >>> > Diego >> >>> > >> >>> > _______________________________________________ >> >>> > dev mailing list >> >>> > [email protected] >> >>> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >>> > >> >> >> >> >> > >> > _______________________________________________ >> > dev mailing list >> > [email protected] >> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> > >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
