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.
Related
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
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
I'd like to add an offsite Windows VM to Azure Arc for health monitoring. The VM is hosted by Vultr and runs Windows Server 2016 Standard Build 14393.
However, installing AzureConnectedMachineAgent.msi on the target VM fails with error code 1603. Installation log also contains this error:
Start-Service : Service 'Guest Configuration Extension service
WixQuietExec64: (ExtensionService)' cannot be started due to the following error: Cannot start
WixQuietExec64: service ExtensionService on computer '.'.
WixQuietExec64: At C:\Program Files\AzureConnectedMachineAgent\ExtensionService\GC\Modules\Exte
WixQuietExec64: nsionService\ServiceHelper.psm1:367 char:5
Any suggestions on how to fix this?
You may Check if the user with which you are logged into the VM have
sufficient permissions to start a system service
If you find the following in the
%ProgramData%\AzureConnectedMachineAgent\Log\himds.log or in installation logs :
time="2021-02-11T08:39:38-08:00" level=error msg="Cannot open event source: Azure Hybrid Instance Metadata Service."
You can verify the permissions by collecting the following registry
key from an impacted server.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomS
Mitigation can be to grant the permission to write to the
SECURITY_SERVICE_RID S-1-5-6 which would grant the required
permissions to the himds service account.
https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids.
If the registry key does NOT exist on the impacted VM, then this
resolution will NOT apply as there will be a separate root cause such
as AV interference.
If the root cause is not found here ,then a procmon trace needs to be
taken to analyze the root cause for the msi not being able to start a
service.
( In case a procmon trace has to be analyzed , please open an MS
Support ticket)
To get support for Windows Agent and extensions in Azure, the Windows
Agent on the Windows VM must be later than or equal to version
2.7.41491.911. However the cause for the failure of agent installation is different in this case.
You may also want to check %programdata%\ext_mgr_logs\gc_ext_telemetry.txt log which must have had an entry something like this :
<GCLOG>........ Not starting Extension Service since machine is an Azure VM</GCLOG>
Cause:
This can happen while attempting to install the agent on an Azure VM.This is an unsupported production scenario.One Should not be installing this agent on an Azure VM as it conflicts with the Azure Guest Agent and interferes with Azure VM management.
If one wishes to use an Azure VM simply for testing purposes then
they can follow the below document for guidance
https://learn.microsoft.com/en-us/azure/azure-arc/servers/plan-evaluate-on-azure-virtual-machine
I am building a Release Pipeline on Azure DevOps. Part of my release is to copy a bunch of files to the Azure VM. As far as I understand, the target machine needs to have PowerShell 5986 port open.
I have a VM with port 5986 open (I verified that by invoking remotely some commands on this VM with "PowerShell on Target Machines" task).
I added "Windows Machine File Copy" task and filled fields:
- Source
- Machines
- Admin Login
- Password
- Destination Folder
In "Machines" field, I put IP of the target machine.
As a result of running the release, I'm getting an error:
Failed to Create PSDrive with Destination:
'\\11.11.11.11\C$\TargetDirectory',
ErrorMessage: 'The network path was not found' The network path was
not found
I also tried to put IP address with a port, in this form: 11.11.11.11:5986
Then, I got this error:
Cannot convert value "\23.97.151.221:5986" to type "System.Uri".
Error: "Invalid URI: The hostname could not be parsed."
Documentation (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/windows-machine-file-copy?view=azure-devops) says that IP address with a port is allowed.
What's the issue here?
I was getting the exact same error while doing these:
Initially in my release pipeline, I had an agent job and I created a Windows machine file copy task under the job and filled in all details correctly. I set the Machines field with the public IP address of my target server (a Windows azure VM) and I always got this error you reported.
I tried to use the Azure file copy task instead but I was faced with another problem (error message: Unable to get FQDN for all resources in ResourceGroup: {resourceGroupName}) which I couldn't get to fix after a lot of efforts.
This is the solution that worked for me:
Instead of running an agent job, I ran a Deployment Group Job. With deployment groups, I didn't need an IP address to connect to my VM. Setting up a deployment group for your Azure VM is very simple and well explained here
I created a Windows Machine File Copy task under the Deployment Group job I added. I filled same details for the task except that instead of the IP address of the Windows VM, I entered the computer name in the Machines field and the file copy task ran successfully!
I hope this helps
The problem is because you can't use that task to copy files across Windows Domain boundary! That is to say, if you build on host A and want to copy files to host B, then A and B must be in the same Windows Domain, otherwise you'll get the error like
##[error]Failed to Create PSDrive with Destination: '\\your-server-name-or-ip\some\path', ErrorMessage: 'The network path was not found'
That is to say, if you're using a hosted agent, then you're not able to copy files with that task to any host you have, no matter it has a public IP or not, or a FQDN, because they are not in the same Windows Domain!
You have two options to work around it:
Use Azure File Copy task if your target is an Azure VM or Azure Storage
Use private hosted agent and make sure your target host and your private agent are in the same Windows Domain
Last but not least, the document should really make it clear! It wasted me a lot of time on solving the problem!
go to the destination folder, right-click the folder select properties,share option is there, click that one and share everyone option is there
The solution is to go to the target server and SHARE the directory where the files would be copied. In Windows, just go to Properties of the directory, Sharing tab, and Share it to the user which is used in the VSTS task.
The answer is pretty simple, the DevOps Tasks are actually running PowerShell on you VM and trying to create a PSDrive.
Try using the task mentioned in the screenshot below:
I have 2 sites. Each site has one SCVMM configured to do Azure Site Recovery
ASR is configured to replicate the VM form one site to another.
Here is the issue, my VM size is big and i want to do the initial replication offline instead of over the Network and it just not allowing me saying permission issues.
Can anyone help me to find, what could be going wrong here?
ERROR MESSAGE
Permissions couldn't be set for one or more hosts on the initial replication folder path.
Provider error code: 31218
Provider error message:
The VMM service couldn't provide permissions for cs\nimbl[enter image description here][1]ecs1$ on \\nimblecs1\f$. Error: Object reference not set to an instance of an object.. During cloud configuration, the VMM service provides permissions for Hyper-V service accounts on the import and export paths used for initial replication.
Provider error possible causes:
The VMM service doesn't have the required privileges to modify the permissions on the import and export paths.
Provider error recommended action:
Ensure that the VMM service account has the required privileges to perform this operation.
POSSIBLE CAUSES
Verify that the initial replication path exists and is accessible.