I made a file on Azure using "File Service" and then tried to mount it using "connect". It has given me the username: localhost\xyz.
Two questions:
why username starting from "localhost" and not with "Azure"?
why I am unable to mount as windows security not giving any error, instead keep on turning back to credentials page?
p.s. TCP port 445 working properly..
Here are a few workarounds that worked for us.
WAY-1
You can directly go to your PowerShell of your machine and paste the script that you have provided in your storage account
WAY-2
You can click on More options and select for different account and then use the storage account name prepended with AZURE\ as the username and a storage account key as the password.
WAY-3
You can create a file share directly by unchecking the connect using different credentials.
OUTPUT:
For all the above ways here is the screenshot of fileshares that got mounted.
REFERENCES:
Mount SMB Azure file share on Windows
Related
I am trying to set home directory for FTP Server created on Azure VM (Linux) and I tried many ways taking help of google, but it throws error saying
If I add $USER in local_root while modifying /etc/vsftpd.conf file
ftp> mkdir blob
550 Create directory operation failed.
If I dont use $USER
500 OOPS: cannot change directory:/home/ftp
I have set below configuration in /etc/vsftpd.conf file
listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
anon_upload_enable=YES
anon_mkdir_write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
user_sub_token=$USER
local_root=/home/$USER/ftp
allow_writeable_chroot=YES
pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10010
chroot_list_file=/etc/vsftpd.chroot_list
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=NO
Kindly help in fixing this issue while setting home directory for FTP Server (Azure VM).
I got my answer. We have two ways to short out this issue.
ftpClient.DataConnectionType = FtpDataConnectionType.AutoActive; Though this works out well, but this is not recommended.
ftpClient.DataConnectionType = FtpDataConnectionType.AutoPassive; This is recommended in case of Azure VM.
And to work it out, we need to enable pasv_enable=true in AZURE VM through cmd and also have to enable port range in Azure VM through Portal.
pasv_enable=Yes <br>
pasv_max_port=10010<br>
pasv_min_port=10000
Here is what I found as an explanation on Microsoft link-
A multiregion deployment can use an active-active or active-passive configuration. An active-active configuration distributes requests across multiple active regions. An active-passive configuration keeps warm instances in the secondary region, but doesn't send traffic there unless the primary region fails.
For more explanation please refer the link Azure VM Active Passive
as it makes azure configuration mode which results all the traffic in open mode
Please suggest better approach if any.
I set up a new storage account in the Azure portal, created a file share and then hit the "connect" button in the interface.
net use l: \\sharename.file.core.windows.net\uploaded-images /username accessKey
I put in my key but had no luck:
System error 53 has occurred.
The network path was not found.
I checked my firewall and that wasn't the issue (on the outbound side).
Thanks,
John
The syntax is
net use l: \\mystorageaccount.file.core.windows.net\sharename /USER:mystorageaccount mystorageaccountkey
so you should replace the share name by the storage account name just after "\\" and use the storage account name also as a username. The password is the storage account key.
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.
forgot user name password for a linux (ubuntu) vm. tried to "Reset Remote Access" from the portal, but it is not helping - more than 30 minutes - it still shown in progress. Tried to do it via azure command line. Created a new user with password, but unable to login. SSH says access denied. Should I do any additional steps?
After creating new user you should also reset your SSH connection. You could refer to Reset Access and Manage Users and Check Disks with the Azure VMAccess Extension for Linux for detailed steps.
I'm interested in load balancing 2+ Windows VMs in Azure. My primary requirement, though, is that an 'uploads' folder would need to be consistent between each VM. Files in this folder are FTPed by our admin users, and they would then need to select these files in a C# MVC Web app. As you may connect through FTP to one VM, but a Web connection might be to another, the uploads have to be centralised.
It looked as if the new Azure Files, currently in Preview, would help, in that they let me set up a shared drive that each of the VMs could access. My thought was that FileZilla Server would allow FTPing up to this shared 'drive', and the Web app would access it to show the contents.
I've signed up to the Azure Files Preview, and set up the share, persistently mapping it to Drive Z for the sake of experimentation. I've also created a new user and made sure they too have persistent mapping to this same drive as Z.
But I can't seem to do anything with this outside of the Remote Desktop. FileZilla, despite having its Service set to log on using this new account, won't show the contents of this drive, or write anything to it. Likewise my Web App isn't able to access the file contents, despite switching Passthrough Authentication to this new account for the virtual folder.
Does anyone know any way of accessing this drive either through the network path or drive letter? Is this just not possible with Azure Files as they are? Are there any other solutions to sharing some blobs across VMs, but treating it as a local drive or network share?
[UPDATE]
This might help. Having set up the share, and used cmdkey and net use while in a cmd prompt runas a specially created user (as suggested in http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/27/persisting-connections-to-microsoft-azure-files.aspx), if I point a virtual folder in IIS to this share, using the specific account created, and Test Connection, I get:
Test: Authentication (green tick; "The specified user credentials are valid")
Test: Authorization (red cross; "The path does not exist or environment variables in the path could not be expanded to verify whether it exists.")
While still in a runas cmd prompt, I can access the share, so it's not a specific permissions issue. It just seems to be that IIS cannot use that user to access the share, for some reason. The limitation of Azure Files is that I cannot specifically grant any kinds of permissions on the folder within that share.
What worked for me is the following:
Create a new account
Set the IIS App Pool Identity to a this specific user
Set the IIS App Pool Load User Profile property to true
start a cmd promt as this user (runas)
do cmdkey and net use (with /persistent:true switch), as you described
create IIS Virtual Diretory with physical path set to UNC share path (not the mapped drive)
A little PowerShell snippet for point 5:
$share = "your-storage-account.file.core.windows.net\yoursharename"
$usr = "your-storage-account"
$key = "your-storage-key"
#store credentials for the network share - must be done for the user that will run the app pool
cmdkey /add:subclub.file.core.windows.net\images /user:$usr /pass:$key
net use z: "\\$share" /user:$usr $key /persistent:yes
The answers here proved helpful.
Setup
Create a new user {appuser}
Open a command windows as the user
runas /user:{appuser} cmd.exe
In the new {appuser} cmd window use
cmdkey /add:{storage-account}.file.core.windows.net
/user:{storage-account} /pass:{account-key}
Set the IIS Application pool to use {appuser}
4b. Set LoadUserProfile to true
Notice no need for the net use. Don't need the mapped drive.
Code
Now here's the key piece. From your app you must write to the UNC path.
\{storage-account}.file.core.windows.net\
ex.
File.WriteAllText("\\\\{storage-account}.file.core.windows.net\\share\test.txt", "contents goes here");