This article describes in which way a Common Network Plugin Share placed on to Azure File Storage can be attached to Electric CloudBees CD (CloudBees Flow) Server installed on the top of a Linux box.
Information in this article will help you to avoid difficulties in accessing plugins located on
Azure File Storage.
By default you are using common steps to create your File Share on Azure:
"How to create a file share".
Then you mount that File Share to your Linux box with Electric CloudBees CD (CloudBees Flow) Server accordingly to:
"How to use file share in Linux".
But as result you get "Unable to load page definition" message when you’re accessing Electric CloudBees CD (CloudBees Flow) UI:
Unable to load page definition. Plugin Name: EC-Homepage-18.104.22.168236 File Name: homepage.xml
To resolve mentioned issue we would recommend you to use "noserverino " mount option
when you’re attaching Network Plugins Location based on Azure File Share to your EFlow Server Linux box:
$ sudo mount -t cifs //.file.core.windows.net/plugins //plugins -o noserverino,vers=3.0,username=,password=,dir_mode=0777,file_mode=0777,uid=,gid=
From mount command man page:
Use inode numbers (unique persistent file identifiers) returned by the server instead of automatically generating temporary inode numbers on the client. Although server inode numbers make it easier to spot hardlinked files (as they will have the same inode numbers) and inode numbers may be persistent (which is userful for some sofware), the server does not guarantee that the inode numbers are unique if multiple server side mounts are exported under a single share (since inode numbers on the servers might not be unique if multiple filesystems are mounted under the same shared higher level directory). Note that not all servers support returning server inode numbers, although those that support the CIFS Unix Extensions, and Windows 2000 and later servers typically do support this (although not necessarily on every local server filesystem). Parameter has no effect if the server lacks support for returning inode numbers or equivalent.
Client generates inode numbers (rather than using the actual one from the server) by default.