I have two Linux Azure VMs (Redhat 7.4) that need share a common location for processing files. The VMs are located in Australia East.
I also have a Storage Account that's in Australia East and have created a file share in the Storage Account. I generated the commands to connect the VMs to the file share (by clicking on the file share, then choosing "Connect"), but I get this error when I run the final generated command in the VM:
sudo mount -t cifs //<storageaccount>/<fileshare> /mnt/<storageaccount>/<fileshare> -o vers=3.0,credentials=/etc/smbcredentials/<storageaccount>.cred,dir_mode=0777,file_mode=0777,serverino
... I get this message:
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
I've run the file diagnostic tool script (https://gallery.technet.microsoft.com/Troubleshooting-tool-for-02184089) in the VM and got this error:
Error: Client is not Azure VM in the region as Storage account, mount will fail
I'm confused as it seems to be saying that the VMs and Storage Account are in different locations, when they aren't.
Thanks in advance for any assistance.
I can reproduce this same issue with Redhat 7.4. To fix this, you can make sure that Secure transfer required setting is disabled on the storage account. View more info. Or verify that you input the correct value in each of the parameters in the commands. You could refer to these steps to mount the Azure file share.
sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino
Related
Basically for an application, we're planning to mount a Azure fileshare to directly write the logs to. However we want to create a health check to notify the team if the fileshare mount fails. Can someone help me how I can implement this functionality? Its a RHEL VM in Azure
• Yes, there is a way through which you can check whether the Azure file share has been mounted successfully or not in the Linux VM or not. You can run a script in your Linux VM through custom script extension and check its output whether the azure file share has mounted successfully or not.
Run the script in the below github link named ‘AzFileDiagnostics.sh’ in your RHEL Linux VM through the commands as below: -
Github link : - https://github.com/Azure-Samples/azure-files-samples/tree/master/AzFileDiagnostics/Linux
Commands for the script to run: - ‘sudo bash AzFileDiagnostics.sh’ or ‘sudo bash AzFileDiagnostics.sh -u //storageaccountname.file.core.windows.net/sharename’
Output: -
• This script when run will check all the prerequisites for connecting to Azure File share like checking port 445 TCP, SMB 3.3 for encryption purposes, cifs-utils package is installed or not, etc., and when all these requirements are met, it will mount the azure file share through the commands as stated above. Also, you can check the diagnostics logs through monitoring section by enabling them and collecting logs regarding this script for connection details.
Please find the below link for more reference: -
https://learn.microsoft.com/en-us/azure/storage/files/storage-troubleshoot-linux-file-connection-problems#solution
Mounted Azure File shares in AKS deployments using Cluster UAMI with Reader & Storage account key operator service role. It was successfully mounted in all the POD replicas and able to create the files/list all the files of Azure file share from a pod. But, it is not working after key rotation. Also, I tried to create new deployment, storage class, PVC. Still, facing permission issues while PODs are getting created.
Stage 1: (First Time Process)
Created AKS Cluster, Storage File share, User managed Identity.
Assigned the UAMI to Cluster and provided the Reader & Storage account key operator service roles in new storage scope.
Created new Custom Storage class, PVC, deployments.
Result: All functionalities were working as expected.
Stage 2: (Failure Process)
Created new deployment after key rotation as existing PODs were unable to access the Azure File Share. Permission issue.
Then, Created new Storage Class/PVC/deployment - Still same permission issue.
Error:
default 13s Warning FailedMount pod/myapp-deploymentkey1-67465fb9df-9xcrz MountVolume.SetUp failed for volume "xx" : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t cifs -o file_mode=0777,dir_mode=0777,vers=3.0,actimeo=30,mfsymlinks,<masked> //{StorageName}.file.core.windows.net/sample1 /var/lib/kubelet/pods/xx8/volumes/kubernetes.io~azure-file/pvc-cxx
Output: mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
default 13s Warning FailedMount pod/myapp-deploymentkey1-67465fb9df-jwmcc MountVolume.SetUp failed for volume "xx" : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t cifs -o file_mode=0777,dir_mode=0777,vers=3.0,actimeo=30,mfsymlinks,<masked> //{StorageName}.file.core.windows.net/sample1 /var/lib/kubelet/pods/xxx/volumes/kubernetes.io~azure-file/pvc-xx
Output: mount error(13): Permission denied
• The error that you are encountering while mounting file share on the Kubernetes pod represents that there is communication protocol issue, i.e., the communication channel used to connect to the azure file share and mount it on the pod after key rotation is unencrypted and the connection attempt was made from different location of Azure datacenter than where the file share resides.
• Also, please check whether ‘Secure Transfer’ required property for the storage account is enabled or not because if it is enabled, then any requests originating from an insecure connection are rejected. Microsoft recommends that you always require secure transfer for all your storage accounts.
• So, for this issue, you can try disabling the ‘secure transfer’ property on the file share storage account as the files share will be shared for all the existing pods so if a new pod deployment with new key rotation related to the user assigned managed identity is detected, the existing ones might not be compatible with the new keys assigned or may not be updated with it.
• You can also check the version of SMB encryption used for the existing pods and the newly deployed ones. Please refer the below links for more information: -
https://learn.microsoft.com/en-us/answers/questions/560362/aks-file-share-persistent-mounting-with-managed-id.html
https://learn.microsoft.com/en-us/azure/storage/files/storage-troubleshoot-linux-file-connection-problems#mount-error13-permission-denied-when-you-mount-an-azure-file-share
I don't know how to connect to an existing Azure File Share from Azure Cloud Shell.
The command clouddrive seems to move my default cloud shell storage account. But I don't want to do that. I just want to access my existing Azure File Share storage. This can exist in any Azurea region (not just what's available for Cloud Shell, which is currently very limited)
When I tried to use clouddrive to mount my existing Azure Files account, I get the following error message:
ERROR: The storage account is not in the valid location. Expect: eastus Actual: canadacentral
I'd prefer not to move my existing Azure File Shares from canadacentral to eastus. Is there a workaround for this?
I'd like to just connect to my existing Azure File Shares through Cloud Shell and run commands in those directories.
Thank you!
Same question asked here:
https://github.com/MicrosoftDocs/azure-docs/issues/42001
https://serverfault.com/questions/992834/connect-to-azure-file-share-from-azure-cloud-shell
Azure cloud shell is an interactive, authenticated, browser-accessible shell which backend is running on cloud shell hosts. The cloud shell machines are temporary but your files are persisted through a mounted file share named clouddrive.
By using the advanced option, you can associate existing resources. Also, the associated Azure storage accounts must reside in the same region as the Cloud Shell machine that you're mounting them to. To find your current region you may run env in Bash and locate the variable ACC_LOCATION.
As the document stated, the canadacentral is not an available region for Cloud Shell, you should mount file storage in the available region. If so, you can run clouddrive unmount to unmount the current file share then select the existing file storage in the available region via clicking advanced settings in the initial login.
Technical Stack
MarkLogic 9.0
Cenos Linux
Azure Blob
Blobfuse
To make sure we do not have to worry about data disk size for MarkLogic Forest, we have configured Azure Blob to one of folder in Linux machine, so we do not have to worry about disk size.
There are few things i noticed
Need to create folder in Linux
Create folder and point it to above folder
Then configure Blobfuse else we are getting permission denied while creating forest
Use below command to give permission to all
chmod 777 -R
Now when we started importing using MarkLogic Content Pump (MLCP)
19/03/15 17:01:19 ERROR mapreduce.ContentWriter: SVC-FILSTAT: File status error: stat64 '/mnt/mycontainer/Forests/forest-01/000043e5': Permission denied
So if you look at below image
1st we tried with mycontainer but as soon as we map it to Azure Blob, it does not looks green as azureblob which is. We still need to map azureblob to "azureblob" folder.
It seems i am missing something here, anything to do with Azure Blob security settings?
With the test, when you mount the Azure Blob to Linux, for example, Ubuntu 18.04 (which I'm using), if you want to allow other users to use the mount directory, you can add the parameter -o allow_other when you execute the command blobfuse.
To allow access to all users, you can mount via the option -o
allow_other.
Also, I think you should give others permission through the command chown. For more details, see How to mount Blob storage as a file system with blobfuse.
First i would like to thanks Charles for his efforts and extended help on this issue, Thanks Charls :). I am sure this will help me sometime, somewhere.
I got link on how to setup MarkLogic on Aure
On Page No. 27, steps to Configuring MarkLogic for Azure Blob Storage
In summary it is
Create Storage account in Azure
Create Blob container
Go to MarkLogic server (http://localhost:8001)
Go to Security -> Credentials
Provide Storage account and Azure storage key
While creating MarkLogic Forest, mentioned container path in data directory
azure://mycontainer/mydirectory/myfile
And you are done. No Blobfuse, no drive mount, just a configuration in MarkLogic
Awesome!!
Its working like dream :)
I successfully mounted a Azure File Storage to a VM which is inside the same subscription and location. Now I cloned this VM to a new subscription and another location - so my new machine is exactly the same except of subscription and location. When I run the same command for mounting the same file storage:
sudo mount -t cifs //MYACCOUNT.file.core.windows.net/MY/FOLDER /MY/LOCAL/FOLDER/ -o vers=3.0,username=USER,password=ACCESSKEY,file_mode=0777,dir_mode=0777
then I get
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
I think it has something to do with the different subscription and location, because in the portal when I click on connect in my file storage it is said:
To connect to this file share, run this command from any Windows virtual machine on the same subscription and location:
So is there any possibility to connect to my file storage from within another subscription and location?
You need to use the SMB 3.0 protocol to connect outside of that Azure region. This page says it's not supported on Linux:
https://azure.microsoft.com/en-us/documentation/articles/storage-how-to-use-files-linux/
Note that since the Linux SMB client doesn’t yet support encryption, mounting a file share from Linux still requires the client to be in the same Azure region as the file share. However, encryption support for Linux is on the roadmap of Linux developers responsible for SMB functionality.
Edit: There is an update on Ubuntu here.