在Hosted Linux Agent上运行VSTS构建期间挂载Azure文件存储失败

Question

I've got a storage account (classic) setup with a file share. I used the information from "Connecting from Linux" ( https://docs.microsoft.com/en-us/azure/storage/storage-file-how-to-use-files-portal#connect-to-file-share ) to mount the share as a build step using the following shell script:

sudo apt-get -y update
echo Installing cifs-utils

sudo apt-get -y install cifs-utils

SHARE=$PWD/buildartifacts
echo Creating $SHARE
if [ ! -d $SHARE ]; then
  sudo mkdir $SHARE
fi

echo Mounting $SHARE
sudo mount -t cifs $1 $SHARE -o vers=3.0,username=$2,password=$3,dir_mode=0777,file_mode=0777

I pass in the share path, username and password from the VSTS build.

This is the tail of the output I get from the build:

2017-07-12T11:56:01.0208730Z Creating config file /etc/samba/smb.conf with new version
2017-07-12T11:56:01.2016540Z Setting up libcap-ng0:amd64 (0.7.7-1) ...
2017-07-12T11:56:01.2433760Z Setting up libtalloc2:amd64 (2.1.5-2) ...
2017-07-12T11:56:01.2823630Z Setting up cifs-utils (2:6.4-1ubuntu1.1) ...
2017-07-12T11:56:01.3532550Z Setting up keyutils (1.5.9-8ubuntu1) ...
2017-07-12T11:56:01.4042470Z Setting up libtdb1:amd64 (1.3.8-2) ...
2017-07-12T11:56:01.4382800Z Setting up libtevent0:amd64 (0.9.28-0ubuntu0.16.04.1) ...
2017-07-12T11:56:01.4748150Z Setting up libldb1:amd64 (2:1.1.24-1ubuntu3) ...
2017-07-12T11:56:01.5114810Z Setting up python-crypto (2.6.1-6ubuntu0.16.04.2) ...
2017-07-12T11:56:01.9924790Z Setting up python-ldb (2:1.1.24-1ubuntu3) ...
2017-07-12T11:56:02.0912580Z Setting up python-tdb (1.3.8-2) ...
2017-07-12T11:56:02.1932370Z Setting up python-talloc (2.1.5-2) ...
2017-07-12T11:56:02.2329750Z Setting up samba-libs:amd64 (2:4.3.11+dfsg-0ubuntu0.16.04.8) ...
2017-07-12T11:56:02.2687050Z Setting up python-samba (2:4.3.11+dfsg-0ubuntu0.16.04.8) ...
2017-07-12T11:56:02.6471400Z Setting up samba-common-bin (2:4.3.11+dfsg-0ubuntu0.16.04.8) ...
2017-07-12T11:56:02.6860280Z Processing triggers for libc-bin (2.23-0ubuntu7) ...
2017-07-12T11:56:02.8437710Z Creating /opt/vsts/work/1/s/buildartifacts
2017-07-12T11:56:02.8522080Z Mounting /opt/vsts/work/1/s/buildartifacts
2017-07-12T11:56:02.8613570Z Unable to apply new capability set.
2017-07-12T11:56:02.8828840Z ##[error]/bin/bash failed with return code: 2
2017-07-12T11:56:02.8873290Z ##[error]Bash failed with error: /bin/bash failed with return code: 2
2017-07-12T11:56:02.9474600Z ##[section]Finishing: Shell Script setup-hosted.sh

I have managed to get this working on the Windows Hosted Agent where I used:

net use <share> /u:AZURE\<username> <password>

The difference here is that I then access the files directory without a drive letter:

/path/to/file It seems that the Hosted Linux Agent for VSTS is not configured to allow mounting cifs shares. Is this correct and the expected behavior?

Additional information:

The VM capability set returned by:

sudo capsh --print

outputs:

Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)

According to the capabilities(7) man page:

CAP_SYS_ADMIN
          * Perform a range of system administration operations including: quotactl(2), mount(2), umount(2), swapon(2), swapoff(2), sethostname(2), and setdomainname(2);

and from mount(2):

Appropriate privilege (Linux: the CAP_SYS_ADMIN capability) is required to mount filesystems.

Answer 1

The agent for the "Hosted Linux Preview" pool is actually running inside of a container, and it looks like special capabilities are required for mounting that filesystem while running inside a container.

Deeper integration with Docker and containers is planned for VSTS very soon, which should lead to a change in how the "Hosted Linux Preview" pools work in general.

Until then, a (slightly hacky) work-around could involve spinning up a second container with the correct capabilities (the host's docker daemon is mounted inside of the container the agent is running in) to mount the drive in a shared folder with the current agent container.

Answer 2

The Linux SMB3 client doesn't support share level encryption yet, so mounting a file share in Linux only works from virtual machines running in the same Azure region as the file share.

Go to settings page of your VSTS and check Region ( https://[account].visualstudio.com/_admin/_home/settings ), then compare with your storage region.