When mounting remote directories via SSHFS, a common frustration occurs when non-owner users attempt to access the mounted directory. While the owner (user xxx in this case) can access the content normally, other users (like zzz) encounter mysterious "??????????" listings and "Permission denied" errors.

The fundamental problem lies in how SSHFS handles permissions by default. SSHFS operates with the default_permissions mount option enabled, which means it respects the remote server's permission settings. However, there are additional client-side permission layers that come into play:

# On the remote server:
$ ls -ld /mnt/content
drwxr-xr-x 6 xxx xxx 4096 Jul 25  2011 /mnt/content

# On the client (as zzz):
$ ls -ld /home/xxx/path_to/content
d????????? ? ? ? ? ? content

Several permission layers stack up:

1. Remote server permissions (xxx:xxx with 755)
2. SSHFS mount point parent directory permissions
3. User and group mappings between systems
4. Client-side FUSE configuration

Here are three approaches to resolve this:

1. Using the allow_other Mount Option

The most straightforward solution is adding allow_other to your mount options:

sshfs -o allow_other -o kernel_cache -o auto_cache -o reconnect \
      -o compression=no -o cache_timeout=600 -o ServerAliveInterval=15 \
      xxx@yyy.yyy.yyy.yyy:/mnt/content /home/xxx/path_to/content

Note: This requires either running as root or setting user_allow_other in /etc/fuse.conf.

2. Adjusting Parent Directory Permissions

Ensure the parent directory has proper execute permissions:

$ chmod o+x /home/xxx
$ chmod o+x /home/xxx/path_to

3. Using uid/gid Mapping

Explicitly map user IDs if they differ between systems:

sshfs -o uid=$(id -u zzz) -o gid=$(id -g zzz) \
      xxx@yyy.yyy.yyy.yyy:/mnt/content /home/xxx/path_to/content

When using allow_other, be aware that:

• This makes the mounted filesystem accessible to all users
• Remote permissions still apply (users can't access what the remote server denies)
• Consider combining with umask if you need to restrict access further

For systems with multiple regular users needing access:

# As root:
mkdir /mnt/shared_content
sshfs -o allow_other xxx@remote:/mnt/content /mnt/shared_content
chmod a+rx /mnt/shared_content

Then users can access through /mnt/shared_content while maintaining proper permission controls.

---

When working with SSHFS-mounted directories, a common frustration emerges: why can't other users access mounted directories even when the permissions seem correct? Let's dissect this specific scenario where user xxx can access the mounted directory but user zzz gets permission denied errors.

The key observation here is the mysterious d????????? output when user zzz attempts to list the mounted directory. This typically indicates that:

• The FUSE layer is enforcing permissions
• The parent directory's permissions prevent access
• The SSHFS mount options may need adjustment

SSHFS operates through FUSE (Filesystem in Userspace), which means:

1. All access checks are performed in userspace
2. By default, FUSE respects Unix permissions strictly
3. The mounting user's permissions become the gatekeeper

In your case, the mount point /home/xxx/path_to/content is owned by xxx, and the default SSHFS behavior doesn't allow other users to traverse this path.

Here are three approaches to solve this:

Solution 1: Use allow_other Mount Option

Modify your mount command:

sshfs -o kernel_cache -o auto_cache -o reconnect -o compression=no \
      -o cache_timeout=600 -o ServerAliveInterval=15 \
      -o allow_other \
      xxx@yyy.yyy.yyy.yyy:/mnt/content /home/xxx/path_to/content

Important: You'll need to uncomment user_allow_other in /etc/fuse.conf on most systems.

Solution 2: Adjust Directory Permissions

Ensure the mount point and parent directories have execute permissions:

chmod a+x /home/xxx
chmod a+x /home/xxx/path_to

Solution 3: Use uid/gid Mapping

If users have different UIDs across systems:

sshfs -o uid=$(id -u zzz),gid=$(id -g zzz) \
      xxx@yyy.yyy.yyy.yyy:/mnt/content /home/xxx/path_to/content

When using allow_other:

• Any system user can access the mounted filesystem
• Consider combining with default_permissions option
• For production systems, evaluate if this is acceptable

If issues persist:

# Check FUSE configuration
cat /etc/fuse.conf

# Verify mount options
mount | grep sshfs

# Test basic SSH access
ssh xxx@yyy.yyy.yyy.yyy ls -la /mnt/content

For multi-user systems, consider:

sudo mkdir /mnt/shared_content
sudo sshfs -o allow_other xxx@yyy.yyy.yyy.yyy:/mnt/content /mnt/shared_content
sudo chmod a+rx /mnt/shared_content

This creates a system-wide accessible mount point while maintaining security through standard Unix permissions.