Open seanhig opened 7 years ago
Hi @seanhig Yes this is a very reasonable requirement and we will add this support to allow users setup their options asap. We will update you in this issue when the feature is in.
However regarding to NFS server, it's not yet possible to be used for vFile currently due to swarm privilege limitation.
@seanhig What is exactly your use case? What do you mean you expect the share to be owned by "www-data"? Do you expect "www-data" have both read/write access to the share or read only access? Could you explain your case in detail? If possible, we can have a call to better understand your use case.
Sure we can have a call if you like, feel free to reach out via my email directly.
My current use case is simple: Drupal7 will not work with your vFile implementation. If you take the stock drupal:7 docker image and attempt to use it with vFile (mapping the /var/www/html/sites/default/files to the vFile share), it will fail to write to the share, regardless of the fact that the permissions are wide open.
I suspect this has to do with ownership checks Drupal performs, but I am not certain. The account context within the container is www-data, and this is the ownership it expects.
What I did notice is that in the vFile code: https://github.com/vmware/docker-volume-vsphere/blob/master/client_plugin/drivers/vfile/dockerops/dockerops.go https://github.com/vmware/docker-volume-vsphere/blob/master/client_plugin/drivers/vfile/dockerops/dockerops.go
You are hardcoding certain values like:
SambaUsername = “root”, SambaPassword = "badpass"
Unless I missed something, it is not possible to affect these values… I think it would be handy if we could control many of them as part of the vFile configuration.
Cheers, Sean
On Nov 29, 2017, at 5:51 PM, Liping Xue notifications@github.com wrote:
@seanhig https://github.com/seanhig What is exactly your use case? What do you mean you expect the share to be owned by "www-data"? Do you expect "www-data" have both read/write access to the share or read only access? Could you explain your case in detail? If possible, we can have a call to better understand your use case.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vmware/docker-volume-vsphere/issues/1948#issuecomment-348046754, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfQozDfA7m6FF0vn-BfZFtwxayavo87ks5s7fwvgaJpZM4QFK_b.
@seanhig do you expect to be able to provide a user account name/ID or group account name/ID that can be used to control access to the volume? Possibly allow all users in a group to be able to share the same volume? Or exclusive that only a specific user/group can access the volume.
For the username and password, it should be possible to use secrets (IIRC, docker does implement these storage plugins as services and its feasible to provide secrets to the service).
@seanhig What is your email? From what you described, it seems that the share is mount successfully but unable to write. Or the cifs mount fail? Let us have a phone call tomorrow.
Hi
I'm also unable to modify permissions and ownership.
I have VMs on Oracle Linux 7 UEK R4, ESX 6.5.
# uname -a
Linux deploy01 4.1.12-124.17.1.el7uek.x86_64 #2 SMP Thu Jul 5 14:53:45 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
# docker -v
Docker version 17.06.2-ol, build d02b7ab
# vmware-toolbox-cmd -v
10.1.10.63510 (build-6082533)
After mounting a vFile volume, chmod and chown have no effect. It is problematic in the case where I use elastic search.
For example, the file node.lock cannot be written by the elastic search process which runs under the user id '1000'.
root@21dd76833d19:/#` ls -lah /restore/nodes/0/node.lock
-rwxr-xr-x` 1 root root 0 Feb 28 20:17 /restore/nodes/0/node.lock
Thank you for your help Pierre-Luc
I am having the same issue as @plcouture. ElasticSearch wants the storage volume to be writable by the elasticsearch user and/or group (1000:1000). After creating and mounting the vFile share, I am unable to change the permissions with chown/chmod.
I am having the same issue as @plcouture. ElasticSearch wants the storage volume to be writable by the elasticsearch user and/or group (1000:1000). After creating and mounting the vFile share, I am unable to change the permissions with chown/chmod.
Hi
I'm also unable to modify permissions and ownership.
I have VMs on Oracle Linux 7 UEK R4, ESX 6.5.
# uname -a Linux deploy01 4.1.12-124.17.1.el7uek.x86_64 #2 SMP Thu Jul 5 14:53:45 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux # docker -v Docker version 17.06.2-ol, build d02b7ab # vmware-toolbox-cmd -v 10.1.10.63510 (build-6082533)
After mounting a vFile volume, chmod and chown have no effect. It is problematic in the case where I use elastic search.
For example, the file node.lock cannot be written by the elastic search process which runs under the user id '1000'.
root@21dd76833d19:/#` ls -lah /restore/nodes/0/node.lock -rwxr-xr-x` 1 root root 0 Feb 28 20:17 /restore/nodes/0/node.lock
Thank you for your help Pierre-Luc
Hi Pierre-Luc,
Whether this problem has been resolved ? I am having the same issue.
Thanks in advance
Hi Pierre-Luc,
Whether this problem has been resolved ? I am having the same issue.
Thanks in advance
Hi
The problem has not been resolved as far as I know. You should take a look a this comment regarding the status of the project : https://github.com/vmware/vsphere-storage-for-docker/issues/2091#issuecomment-470404601
pretty sure this project is completely deprecated.
On Mon, Oct 14, 2019 at 6:34 PM plcouture notifications@github.com wrote:
Hi Pierre-Luc,
Whether this problem has been resolved ? I am having the same issue.
Thanks in advance
Hi
The problem has not been resolved as far as I know. You should take a look a this comment regarding the status of the project : #2091 (comment) https://github.com/vmware/vsphere-storage-for-docker/issues/2091#issuecomment-470404601
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vmware/vsphere-storage-for-docker/issues/1948?email_source=notifications&email_token=AAD5BI67HUECUQTQJQCXXMDQOUF2HA5CNFSM4EAUV7N2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBHAXVI#issuecomment-541985749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5BI63FPKYHFRUWCZWVADQOUF2HANCNFSM4EAUV7NQ .
-- Cheers, Sean Hignett, Intelligent Design Studios http://www.intelligent-design.ca 403.650.7981
I tried to use vFile plugin to create a files share for multiple Drupal front ends. The CIFS share is mounted using the "root" user, but Drupal is expecting the share to be owned by "www-data".
There doesn't appear to be anyway to change the CIFS permissions, or file mode, or the SambaUsername used to mount the share. Would it be possible to have more flexibility in the CIFS mounting options?
Maybe an option to spin up an NFS server instead of CIFS?
How would we control the access account for the vFile shares so it aligns with the expected permissions?
Thanks.