27

I try to sshfs mount a remote dir, but the mounted files are not writable. I have run out of ideas or ways to debug this. Is there anything I should check on the remote server?

I am on an Xubuntu 14.04. I mount remote dir of a 14.04 Ubuntu.

local $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

I changed the /etc/fuse.conf

local $ sudo cat /etc/fuse.conf
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
#mount_max = 1000

# Allow non-root users to specify the allow_other or allow_root mount options.
user_allow_other

And my user is in the fuse group

local $ sudo grep fuse /etc/group
fuse:x:105:MY_LOACL_USERNAME

And I mount the remote dir with (tried with/without combinations of sudo, default_permissions, allow_other):

local $sudo sshfs -o allow_other,default_permissions -o IdentityFile=/path/to/ssh_key  REMOTE_USERNAME@REMOTE_HOST:/remote/dir/path/  /mnt/LOCAL_DIR_NAME/

The REMOTE_USERNAME has write permissions to the dir/files (on the remote server).

I tried the above command without sudo, default_permissions, and in all cases I get:

local $ ls -al /mnt/LOCAL_DIR_NAME/a_file
-rw-rw-r-- 1 699 699 1513 Aug 12 16:08 /mnt/LOCAL_DIR_NAME/a_file
local $ test -w /mnt/LOCAL_DIR_NAME/a_file && echo "Writable" || echo "Not Writable"
Not Writable

Clarification 0

In response to user3188445's comment:

$ whoami
LOCAL_USER
$ cd
$ mkdir test_mnt
$ sshfs -o allow_other,default_permissions -o IdentityFile=/path/to/ssh_key  REMOTE_USERNAME@REMOTE_HOST:/remote/dir/path/ test_mnt/

$ ls test_mnt/
I see the contents of the dir correctly

$ ls -al test_mnt/
total 216
drwxr-xr-x  1 699 699  4096 Aug 12 16:42 .
drwxr----- 58 LOCAL_USER LOCAL_USER  4096 Aug 17 15:46 ..
-rw-r--r--  1 699 699  2557 Jul 30 16:48 sample_file
drwxr-xr-x  1 699 699  4096 Aug 11 17:25 sample_dir


$ touch test_mnt/new_file 
touch: cannot touch ‘test_mnt/new_file’: Permission denied

# extra info: SSH to the remote host and check file permissions
$ ssh REMOTE_USERNAME@REMOTE_HOST
# on remote host
$ ls -al /remote/dir/path/
lrwxrwxrwx 1 root root 18 Jul 30 13:48 /remote/dir/path/ -> /srv/path/path/path/
$ cd /remote/dir/path/
$ ls -al
total 216
drwxr-xr-x 26 REMOTE_USERNAME  REMOTE_USERNAME   4096 Aug 12 13:42 .
drwxr-xr-x  4 root root  4096 Jul 30 14:37 ..
-rw-r--r--  1 REMOTE_USERNAME  REMOTE_USERNAME   2557 Jul 30 13:48 sample_file
drwxr-xr-x  2 REMOTE_USERNAME  REMOTE_USERNAME   4096 Aug 11 14:25 sample_dir
0

5 Answers 5

26

The question was answered in a linux mailing list; I post a translated answer here for completeness.

Solution

The solution is to not use both of the options default_permissions and allow_other when mounting (which I didn't try in my original experiments).

Explanation

The problem seems to be quite simple. When you use the option default_permissions in fusermount then fuse's permission control of the fuse mount is handled by the kernel and not by fuse.

This means that the REMOTE_USER's uid/gid aren't mapped to the LOCAL_USER (sshfs.c IDMAP_NONE). It works the same way as a simple nfs fs without mapping.

So, it makes sense to prohibit the access, if the uid/gid numbers don't match.

If you have the option allow_other then this dir is writable only by the local user with uid 699, if it exists.

From fuse's man:

'default_permissions'

   By default FUSE doesn't check file access permissions, the
   filesystem is free to implement its access policy or leave it to
   the underlying file access mechanism (e.g. in case of network
   filesystems).  This option enables permission checking, restricting
   access based on file mode.  It is usually useful together with the
   'allow_other' mount option.

'allow_other'

   This option overrides the security measure restricting file access
   to the user mounting the filesystem.  This option is by default only
   allowed to root, but this restriction can be removed with a
   (userspace) configuration option.
4
  • 7
    Just a clarification, because I found the explanation a bit unclear: It worked for me by calling sshfs WITH 'allow_other' but WITHOUT 'default_permissions' Commented May 14, 2020 at 12:21
  • For those having group write permission issues with a remote mount via sshfs I used fuse option -o default_permissions per above and I now am able to group write by being member of group with same id on both local and remote machine. Nice!
    – DKebler
    Commented Oct 26, 2020 at 19:28
  • 1
    Can you elaborate with some working examples?
    – jdmayfield
    Commented Nov 14, 2020 at 6:37
  • TL;DR in one command: sudo sshfs -o allow_other user@host:path/to/remote/folder/ path/to/mount/point/
    – Neinstein
    Commented Aug 25, 2023 at 8:16
13

Don't run sshfs with sudo. If you do that, ssh will consider that the file system belongs to root. Run it as yourself, then you will be able to write to the files.

clarification

When running without sudo, you need to mount on your own directory, since you probably can't write to /mnt. So here is an example of how to use sshfs once you have added user_allow_other to /etc/fuse.conf:

$ cd                      # make sure you are in home directory
$ mkdir mnt               # create empty directory
$ sshfs server.com: mnt   # mount my home directory on server.com on ./mnt
$ ls mnt
[contents of home directory on server]
$ touch mnt/new_file      # no problem creating a new file
$ fusermount -u mnt       # unmount file system
$ rmdir mnt
6
  • As I mentioned in the issue, I tried with and without sudo and the result is the same (as far as file permissions and user/group id appearing in ls and the write permission problem) :(
    – vkats
    Commented Aug 14, 2015 at 5:41
  • Can you post the exact commands you are running without sudo and what the output is? Also, are permissions appropriate in /mnt? Without sudo, you would usually want to mount stuff in your home directory rather than a root-owned /mnt directory you probably don't have permissions on. Commented Aug 14, 2015 at 5:51
  • Thanks for the response. I mount to a dir in /mnt but I have the permissions to write on it. I added the set of commands for mounting with sshfs to a dir under my home.
    – vkats
    Commented Aug 17, 2015 at 13:02
  • I encounter the same problem. I try to mount a folder inside /home but the permission doesn't allow me to write data inside the mount point. I already changed the permission of the mount point but it does not work. You say that I must mount inside my own directory. Is this a must? askubuntu.com/q/811057/170070
    – Casper
    Commented Aug 11, 2016 at 18:28
  • This is only true if you use server.com: , ie, mounting the home folder of the ssh user you are using to log in.
    – Pablo A
    Commented Dec 2, 2022 at 18:39
4

One possible reason for this -- one that I hit -- was that I had no more free space on the disk I mounted.

0
1

Another reason for "permission denied" errors: The remote user doesn't have permission to access the files.

It might be obvious in hindsight but worth checking out:

  • Assuming the remote and the local users have the same name (e.g., you ran sshfs remote_machine:/ ~/my_sshfs_mounts/ without providing the user name explicitly), log in with ssh remote_machine
  • Are you able to read and write at the desired directory?
  • If yes: See the other answers to fix SSHFS permission issues.
  • If no: Great, you found a (or the) cause of the problem! Now you need to allow the user you're currently logged in as via SSH to read and write files on the remote machine.

In my case, the remote and local user names were identical but their user IDs differed (1000 vs 1001). You can check by running id. I tried to access files owned by user 1000 as user 1001.

I fixed this by setting the remote user's ID and their group ID from 1001 to 1000 as well. Let's assume the user is called "me". The following steps are mostly inspired by this answer:

  1. ssh root@remote_machine (maybe set PermitRootLogin yes in /etc/ssh/sshd_config)
  2. Change the user's ID: usermod -u 1000 me (maybe kill any processes currently running as user "me")
  3. Change ID of the "me" group: groupmod -g 1000 me
  4. Change ownership of files from user 1001 to 1000: find / -uid 1001 -exec chown -h 1000 {} +
  5. Change group membership of files from group 1001 to 1000: find / -gid 1001 -exec chgrp -h 1000 {} +

After rebooting the remote machine, sshfs remote_machine:/ ~/my_sshfs_mounts/ works now.

0

If you have created mount directory in your home directory assuming that you are the only one going to use it, then run sshfs command without sudo. that way you have necessary permission on mount directory. it should help. sample command example "sshfs -o reconnect, follow_synlinks <user@sshIp:<remote_dir>> <mount_dir>"

2
  • 1
    "synlinks"?  Really? And why do you have an extra ">"? Commented Sep 15, 2022 at 1:34
  • NEVER use SSHFS with sudo except you have a very specific use case and you are a Pro in SSHFS. Access rights are defined elsewhere. I use server sided a sftp-umask 0007 and cliend sided NO default_permissions; remember there are files and directories, the latter get a suidbit and working out of groups becomes possible. of course all UIDs should always be consistent over all computers in potential networks, names are bliss. Commented Apr 14 at 12:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .