Synology NFS confusion
Hi all, I'm trying to set up a hosted engine on an NFS share provided by a Synology NAS. I've been reading the info and threads regarding the requirement that the share be owned by vdsm:kvm with uid:gid of 36:36, but this seems impossible to set on modern Synology boxes. My understanding of DSM is that the user doesn't have control of the UID and GID of users. You can ssh in and modify /etc/passwd but these files are auto-generated from Synology's own scripts so changes here will not persist across reboots. Is that correct? Secondly, having read lots of posts about permissions and various issues around export settings, why isn't this documented anywhere? There just seems to be lots of contradictory posts. For example, my experience has been: - my Synology vdsm:kvm ids are 1028:65536 - the permissions on the NFS export are 777, anything else gives permissions errors in HE setup - the hosted engine install went fine with these settings. - the nfs-check.py script provided to check the NFS export fails but the installation still completes. So are these issues specific to Synology or is the documentation out there just wrong? #confused Cheers, Shareef.
You should be able to just mount the share as the root on any of your oVirt servers to a temp location, say /s-export and do a 'chown vdsm:kvm /s-export' then umount and try and use the export with oVirt. It should have the correct owner and group. I've never used Synology but most any NFS server should allow changing the user and group for the root of the share/export after it mounted. I have to do the same thing before creating an NFS Storage Domain so the user and group are correct. *Justin Willoughby [image: twitter-3-16.png] <https://twitter.com/cohesity> [image: linkedin-6-16.png] <https://www.linkedin.com/company/cohesity>[image: Learn More] <http://signatures.cohesity.com/uc/5967a0e9825be975430b3054>* On Tue, Mar 17, 2020 at 4:23 PM Shareef Jalloq <shareef@jalloq.co.uk> wrote:
Hi all,
I'm trying to set up a hosted engine on an NFS share provided by a Synology NAS. I've been reading the info and threads regarding the requirement that the share be owned by vdsm:kvm with uid:gid of 36:36, but this seems impossible to set on modern Synology boxes.
My understanding of DSM is that the user doesn't have control of the UID and GID of users. You can ssh in and modify /etc/passwd but these files are auto-generated from Synology's own scripts so changes here will not persist across reboots. Is that correct?
Secondly, having read lots of posts about permissions and various issues around export settings, why isn't this documented anywhere? There just seems to be lots of contradictory posts. For example, my experience has been:
- my Synology vdsm:kvm ids are 1028:65536 - the permissions on the NFS export are 777, anything else gives permissions errors in HE setup - the hosted engine install went fine with these settings. - the nfs-check.py script provided to check the NFS export fails but the installation still completes.
So are these issues specific to Synology or is the documentation out there just wrong?
#confused
Cheers, Shareef. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/346B7AVQY3N7L7...
On March 17, 2020 10:21:53 PM GMT+02:00, Shareef Jalloq <shareef@jalloq.co.uk> wrote:
Hi all,
I'm trying to set up a hosted engine on an NFS share provided by a Synology NAS. I've been reading the info and threads regarding the requirement that the share be owned by vdsm:kvm with uid:gid of 36:36, but this seems impossible to set on modern Synology boxes.
My understanding of DSM is that the user doesn't have control of the UID and GID of users. You can ssh in and modify /etc/passwd but these files are auto-generated from Synology's own scripts so changes here will not persist across reboots. Is that correct?
Secondly, having read lots of posts about permissions and various issues around export settings, why isn't this documented anywhere? There just seems to be lots of contradictory posts. For example, my experience has been:
- my Synology vdsm:kvm ids are 1028:65536 - the permissions on the NFS export are 777, anything else gives permissions errors in HE setup - the hosted engine install went fine with these settings. - the nfs-check.py script provided to check the NFS export fails but the installation still completes.
So are these issues specific to Synology or is the documentation out there just wrong?
#confused
Cheers, Shareef.
Actually, I have seen users using anonuid=36,anonguid=36,all_squash (or whatever were the anon user options) which forces all users on the share to be mapped to nfsnobody and that user/group will have uid of '36'. It's worth checking the Sinology documentation. Best Regards, Strahil Nikolov
On 17-3-2020 21:31, Strahil Nikolov wrote:
On March 17, 2020 10:21:53 PM GMT+02:00, Shareef Jalloq <shareef@jalloq.co.uk> wrote:
Hi all,
I'm trying to set up a hosted engine on an NFS share provided by a Synology NAS. I've been reading the info and threads regarding the requirement that the share be owned by vdsm:kvm with uid:gid of 36:36, but this seems impossible to set on modern Synology boxes.
My understanding of DSM is that the user doesn't have control of the UID and GID of users. You can ssh in and modify /etc/passwd but these files are auto-generated from Synology's own scripts so changes here will not persist across reboots. Is that correct?
Secondly, having read lots of posts about permissions and various issues around export settings, why isn't this documented anywhere? There just seems to be lots of contradictory posts. For example, my experience has been:
- my Synology vdsm:kvm ids are 1028:65536 - the permissions on the NFS export are 777, anything else gives permissions errors in HE setup - the hosted engine install went fine with these settings. - the nfs-check.py script provided to check the NFS export fails but the installation still completes.
So are these issues specific to Synology or is the documentation out there just wrong?
#confused
Cheers, Shareef. Actually, I have seen users using anonuid=36,anonguid=36,all_squash (or whatever were the anon user options) which forces all users on the share to be mapped to nfsnobody and that user/group will have uid of '36'.
Yes, thats the way I do it. If you add the exports using the UI you don't get the right lines in /etc/exports but if you enable ssh access you can edit the file and than do: mkdir -p /volume1/ovirt/{he|data} chown -R 36:36 /volume1/ovirt install oVirt using the nfs path your.nas:/volume1/ovirt/he That should work. Greetings, Joop
OK, thanks all. So there are two options here, both of which are to manually chown the directory to the correct 36:36 ownership. And just to understand the side effects of not doing this, given I don't have the correct ownership on the directory, how was oVirt able to installed the HE on this share? What will be the side effects of trying to use this share as it is? On Wed, Mar 18, 2020 at 8:12 AM Joop <jvdwege@xs4all.nl> wrote:
On 17-3-2020 21:31, Strahil Nikolov wrote:
On March 17, 2020 10:21:53 PM GMT+02:00, Shareef Jalloq < shareef@jalloq.co.uk> wrote:
Hi all,
I'm trying to set up a hosted engine on an NFS share provided by a Synology NAS. I've been reading the info and threads regarding the requirement that the share be owned by vdsm:kvm with uid:gid of 36:36, but this seems impossible to set on modern Synology boxes.
My understanding of DSM is that the user doesn't have control of the UID and GID of users. You can ssh in and modify /etc/passwd but these files are auto-generated from Synology's own scripts so changes here will not persist across reboots. Is that correct?
Secondly, having read lots of posts about permissions and various issues around export settings, why isn't this documented anywhere? There just seems to be lots of contradictory posts. For example, my experience has been:
- my Synology vdsm:kvm ids are 1028:65536 - the permissions on the NFS export are 777, anything else gives permissions errors in HE setup - the hosted engine install went fine with these settings. - the nfs-check.py script provided to check the NFS export fails but the installation still completes.
So are these issues specific to Synology or is the documentation out there just wrong?
#confused
Cheers, Shareef. Actually, I have seen users using anonuid=36,anonguid=36,all_squash (or whatever were the anon user options) which forces all users on the share to be mapped to nfsnobody and that user/group will have uid of '36'.
Yes, thats the way I do it. If you add the exports using the UI you don't get the right lines in /etc/exports but if you enable ssh access you can edit the file and than do: mkdir -p /volume1/ovirt/{he|data} chown -R 36:36 /volume1/ovirt install oVirt using the nfs path your.nas:/volume1/ovirt/he
That should work.
Greetings,
Joop _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2IOKWWYWZSKZKV...
Actually, in answer to my own question, having looked at the share permissions, the HE VM was created with the correct 36:36 ownership, it's just that my share has 777 permissions which isn't exactly secure. So in my case there won't be any side effects of this outside of the security implications of having an NFS share with world writable permissions set. On Wed, Mar 18, 2020 at 8:53 AM Shareef Jalloq <shareef@jalloq.co.uk> wrote:
OK, thanks all.
So there are two options here, both of which are to manually chown the directory to the correct 36:36 ownership.
And just to understand the side effects of not doing this, given I don't have the correct ownership on the directory, how was oVirt able to installed the HE on this share? What will be the side effects of trying to use this share as it is?
On Wed, Mar 18, 2020 at 8:12 AM Joop <jvdwege@xs4all.nl> wrote:
On 17-3-2020 21:31, Strahil Nikolov wrote:
On March 17, 2020 10:21:53 PM GMT+02:00, Shareef Jalloq < shareef@jalloq.co.uk> wrote:
Hi all,
I'm trying to set up a hosted engine on an NFS share provided by a Synology NAS. I've been reading the info and threads regarding the requirement that the share be owned by vdsm:kvm with uid:gid of 36:36, but this seems impossible to set on modern Synology boxes.
My understanding of DSM is that the user doesn't have control of the UID and GID of users. You can ssh in and modify /etc/passwd but these files are auto-generated from Synology's own scripts so changes here will not persist across reboots. Is that correct?
Secondly, having read lots of posts about permissions and various issues around export settings, why isn't this documented anywhere? There just seems to be lots of contradictory posts. For example, my experience has been:
- my Synology vdsm:kvm ids are 1028:65536 - the permissions on the NFS export are 777, anything else gives permissions errors in HE setup - the hosted engine install went fine with these settings. - the nfs-check.py script provided to check the NFS export fails but the installation still completes.
So are these issues specific to Synology or is the documentation out there just wrong?
#confused
Cheers, Shareef. Actually, I have seen users using anonuid=36,anonguid=36,all_squash (or whatever were the anon user options) which forces all users on the share to be mapped to nfsnobody and that user/group will have uid of '36'.
Yes, thats the way I do it. If you add the exports using the UI you don't get the right lines in /etc/exports but if you enable ssh access you can edit the file and than do: mkdir -p /volume1/ovirt/{he|data} chown -R 36:36 /volume1/ovirt install oVirt using the nfs path your.nas:/volume1/ovirt/he
That should work.
Greetings,
Joop _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2IOKWWYWZSKZKV...
participants (4)
-
Joop -
Justin Willoughby -
Shareef Jalloq -
Strahil Nikolov