Azure/azure-storage-fuse

problem with accessing mount directory, getting access denied.

Closed this issue · 3 comments

Which version of blobfuse was used?

blobfuse2

Which OS distribution and version are you using?

Ubuntu 22.04.4

If relevant, please share your mount command.

blobfuse2 mount /top_dir/mount_dir1 --config-file=/home/runner/work/workspace/az_storage_mount_config.yml

What was the issue encountered?

trying to mount mount_dir1 and mount_dir2 under /top_dir directory but getting access denied despite directory mode is changed to 777.
below is the output of running in github actions, config file is also printed in it.

code:

sudo mkdir -pv "/top_dir/mount_dir1"
sudo mkdir -pv "/top_dir/mount_dir2"
echo "Assign permissions recursively for /top_dir"
sudo chmod -Rv 777 /top_dir

echo -e "================= blobfuse2 config file ====================="
cat $blobfuse2_config_file_path
echo -e "============================================================="
.
sudo mkdir -pv /mnt/tmp_mount1
echo "Assign permissions recursively for /mnt/tmp_mount1 "
sudo chmod -Rv 777 /mnt/tmp_mount1
      
source_folder_path="/top_dir/mount_dir1"
echo -e "Mounting $source_folder_path using blobfuse2.."
blobfuse2 mount $source_folder_path --config-file=/home/runner/work/workspace/az_storage_mount_config.yml
sudo chmod -R 777 $source_folder_path

logs:

mkdir: created directory '/top_dir'
mkdir: created directory '/top_dir/mount_dir1'
mkdir: created directory '/top_dir/mount_dir2'
Assign permissions recursively for /top_dir
mode of '/top_dir' changed from 0755 (rwxr-xr-x) to 0777 (rwxrwxrwx)
mode of '/top_dir/mount_dir1' changed from 0755 (rwxr-xr-x) to 0777 (rwxrwxrwx)
mode of '/top_dir/mount_dir2' changed from 0755 (rwxr-xr-x) to 0777 (rwxrwxrwx)

================= blobfuse2 config file =====================
allow-other: true
logging:
  type: syslog
  level: log_debug
components:
  - libfuse
  - file_cache
  - attr_cache
  - azstorage
libfuse:
  attribute-expiration-sec: 120
  entry-expiration-sec: 120
  negative-entry-expiration-sec: 240
file_cache:
  path: /mnt/tmp_mount1
  timeout-sec: 120
  max-size-mb: 4096
attr_cache:
  timeout-sec: 7200
azstorage:
  type: block
  account-name: acc_name
  sas: ***
  endpoint: https://acc_name.blob.core.windows.net
  mode: sas
  container: mount_dir1
=============================================================
mkdir: created directory '/mnt/tmp_mount1'
Assign permissions recursively for /mnt/tmp_mount1 
mode of '/mnt/tmp_mount1' changed from 0755 (rwxr-xr-x) to 0777 (rwxrwxrwx)
Mounting /top_dir/mount_dir1 using blobfuse2..
chmod: changing permissions of '/top_dir/mount_dir1': Permission denied
Error: Process completed with exit code 1.

Have you found a mitigation/solution?

if blobfuse2 command ran with sudo, its able to access the directory and mount successfully but then it expects every following command which does something with mount folder content needs to run with sudo which we dont want.

when mounted on container, I want the container user to access the files from mounted directories with sudo as it does currently with blobfuse1 version.

Please share logs if available.

shared above

Blobfuse is successfully mounting even when you run without sudo. The command you use after the mount command sudo chmod -R 777 $source_folder_path is the cause of the error. When you use sudo to mount the directory, it is mounted with root privileges, allowing subsequent sudo commands to modify the directory’s permissions. However, when you mount without sudo, blobfuse does not have the necessary permissions set, preventing it from changing them.

Why are you changing the folder mode sudo chmod -R 777 $source_folder_path again when you have already set the mode to 777 earlier sudo chmod -Rv 777 /top_dir ? This step seems redundant. If you still need to do this then you can try switching to root user mode by running sudo su initially so all your commands will run in root mode.

Chmod of the mounted directory is not supported since its a mount point and not a directory handled by blobfuse. Modification of permissions for dir/file inside using chmod is permissible solely when mounting an HNS-enabled storage account.

okay, you're right.. removing chmod after mounting worked well.. this statement was there from earlier mount command way of mounting.
thanks alot.