SFTP mount messes up folder permissions

What is the problem you are having with rclone?

When mounting my sftp host (external server) to my local folder, the folder permissions are messed up and only the user running rclone can access the folder. Neither --dir-perms nor --file-perms have an impact on permission in the mounted folder.

Run the command 'rclone version' and share the full output of the command.

rclone v1.59.2
- os/version: unknown
- os/kernel: 4.4.180+ (aarch64)
- os/type: linux
- os/arch: arm64
- go/version: go1.18.6
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

SFTP to an external server running Debian 64-bit.

The command you were trying to run

rclone mount remote:downloads/Data /volume1/External/remote/

The rclone config contents with secrets removed.

[remote]
type = sftp
host = remoteserver.com
user = default
key_file = ~/.ssh/id_rsa
shell_type = unix

A log from the command with the -vv flag

2022/09/30 00:21:49 DEBUG : rclone: Version "v1.59.2" starting with parameters ["rclone" "mount" "remote:downloads/Data" "/volume1/External/remote/" "-vv"]
2022/09/30 00:21:49 DEBUG : Creating backend with remote "remote:downloads/Data"
2022/09/30 00:21:49 DEBUG : Using config file from "/var/services/homes/default/.config/rclone/rclone.conf"
2022/09/30 00:21:50 DEBUG : sftp://default@remoteserver.com:22/downloads/Data: New connection 192.168.178.28:38092->46.***.***.***:22 to "SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2"
2022/09/30 00:21:50 DEBUG : sftp://default@remoteserver.com:22/downloads/Data: Shell type "unix" from config
2022/09/30 00:21:50 DEBUG : sftp://default@remoteserver.com:22/downloads/Data: Relative path resolved to "/default/downloads/Data"
2022/09/30 00:21:50 DEBUG : sftp://default@remoteserver.com:22/downloads/Data: Using root directory "/default/downloads/Data"
2022/09/30 00:21:50 INFO  : sftp://default@remoteserver.com:22/downloads/Data: poll-interval is not supported by this remote
2022/09/30 00:21:50 DEBUG : sftp://default@remoteserver.com:22/downloads/Data: Mounting on "/volume1/External/remote/"
2022/09/30 00:21:50 DEBUG : : Root:
2022/09/30 00:21:50 DEBUG : : >Root: node=/, err=<nil>

Additional Information

Host System: Synology NAS running aarch64 GNU/Linux synology_rtd1296_ds220j
Using rclone lsd, rclone mkdir and rclone rmdir, I've ensured that the configuration is good and r/w access on the remote server is working properly.

Now to describe the problem in detail: when mounting my remote with the command specified above, the created mount folder gets a very limiting permission set:
drwx------ 1 default users 0 Sep 30 00:26 remote
This permission set applies to both the root mount folder, as well as all subdirectories and files. This is odd, since the rclone sftp manual states that permissions should be 0777 for dirs and 0666 for files. Therefor I tried to override the permissions using the file-perm and dir-perm flags with the proper permissions (tried 764, 744, 777, with and without leading 0), but it seems to just be ignored. When using these flags, the verbose log (-vv) is identical to the above.

I don't think it matters, but permissions on the folder I'm mounting into, when rclone isn't running, are set up as
drwxrwxrwx+ 2 default users 4096 Sep 29 23:06 remote

I'm currently running the rclone command as a user that's in both the admin and user group. Using the root account made no noticeable difference. Since I am mounting the remote folder onto my NAS, where I want to use the permission system to moderate access to the mount differently for different users, it's not sufficient to run the rclone command as the user I want to access the files with. Access needs to be possible from multiple accounts of the NAS.

I'm clueless as to why this is happening. Hopefully some of you have tipps for me how to get it working, or at least a definitive answer why it is not / will not work.

Thank you for your time.

hello and welcome to the forum,

can you test using --allow-other

Forgot to mention that I also tested that flag. Doesn't make a difference either, ls -l returns the exact same permission set for root, subfolder and files, equivalent to chmod 700.

Try --umask 0 to allow the permissions to include everyone

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.