Raspberry Pi shared drive not mounting

Hi all

I’m reaching out here in the off chance that someone has had the same problem as I’ve been running into for about a year now. I have a raspberry pi (using the default OS) with an external SSD mounted. My hope is to use this as a general shared drive for my household using SSHFS. I have configured my router to grant the Pi a static local IP address, and we have shared SSH keys. So far so good.

My problem is that after a period of time, the drive won’t mount. Using SSH in terminal I also get the error: “ssh: connect to host 192.168.X.XYZ port 22: No route to host”

I’ve checked the router settings and the Pi is connected using the correct IP address.

So far I’ve resolved the problem by reconnecting the Pi to the wifi router, restarting the Pi and/or restarting the router. All of these steps work. Of note, I have changed wifi routers in the meantime and the problem has persisted so it is clearly not the router that is at fault.

In the off chance that anyone has this problem, would you be able to direct me how to solve it? The “solutions” so far need to be repeated at least once a day.

I have a similar setup. Never had this problem.

How did you mount he drive and can you ping your Pi from the client machine when the ssh problem occurs?

Using Raspberry Pi then?

So the pi is losing network

How do you deduct the drive won’t mount if cannot connect using ssh?

How do you reconnect it?

Do you have peripherals connected?

I suspect your issue is the because you are using wlan - ethernet is likely to be more stable. Have you setup the correct wlan country in raspi-config?

sudo raspi-config

Have you tried connecting the Pi directly to the router using ethernet?

Yes I’m using raspbian. I can use the Pi just fine when interacting with it using a monitor, keyboard, mouse etc. It is fully connected to the internet via the wifi network and the correct Wlan country has been selected (not sure how this practically matters?). Using an ethernet cable would be impractical given the layout of my home.

The drive is mounted via USB using whatever default configuration raspbian OS provided - I didn’t mess with the defaults. It is mounted at /media/pi/[DRIVE_NAME]. The issue arises when I try to mount the drive over SSHFS to my laptop and other devices on my home network. After a few hours, the SSH connection drops and I cannot SSH into it any more. Meanwhile, the Pi is connected to the network just fine. I disconnect the Pi from the router (using the Pi’s interface) and reconnect it again, and it works just fine - there is no need for a restart or anything like that. Then a few hours later it starts glitching again…

I may be just conflating issues but I experience the same glitching with KDE connect as well, both on Android and IOS. After a few hours I can’t connect to the raspberry pi, even though it is still actively connected to the wifi network…

Could it be a firewall issue?

This is a system generated automount - not a permanent mount.

This could - partly - explain the disappearance of the shared device.

It could happen because the system - due to the loaded desktop - at some point disconnects peripherals to save power.

That was what I thought when this issue first appeared, but I never installed a firewall and I there doesn’t appear to be one installed either.

What is the connection?

Raspberry Pi OS doesn’t come with KDE Connect.

I think - you are experiencing an IP address conflict in your system network.

That explains why you are experiencing outage involving several different devices.

Such conflict also explains why you cannot reconnect to your ssh service on the pi but the pi itself is connected - just not with the IP you expect.

It may also be a rogue dhcp service - there can be only one.

You can install KDE connect on non-KDE DEs. It allows me to interact with the Pi using my smartphone over wifi (when it works).

Regarding IP address conficts, how do I diagnose/manage that? I have set a dedicated IP address for the Pi on my router already. Is that insufficient?

Every situation is a little different, but here are a couple of things you might want to check.

  1. what specific static address are you giving the RPi ? In my personal experience, I have found an address in the middle to upper range ( the last triad between 175 to 250 ) works best. Some routers prefer / reserve the lower range for DHCP. My router prefers approx 101 to 120 for DHCP addresses with 105 seeming to have special favor with my Linksys router.

  2. in your /etc/fstab make sure the USB SSD is specifically listed with the UUID and not a partition label.


I just remembered, a Dlink router I once had required one to get into the router settings and specify a range of addresses for the router to reserve for static IPs.

Extract some info for your network

ip a | grep wlan

You need the line reading inet ip.x.y.z … broadcast ip.x.y.255 translates to /24

ip route

You need the line reading default via ip.x.y.z …

Your nameserver can be pulled from

cat /etc/resolv.conf

You need the line reading nameserver

  1. Check your router’s dhcp range - one example is a range from ip.x.y.100 to ip.x.y.200.
  2. Select an address outside the dhcp range e.g. ip.x.y.50
  3. Ping the address to ensure nothing is there
  4. Assign your pi a static IP
  5. Rightclick the network icon in upper right corner and open the Settings app
  6. Select the interface and fill in the boxes
    • ipv4 Address = ip.x.y.50/24
    • router = ip for gateway
    • dns servers = ip for nameserver
  7. Save
  8. click network icon and turn off wlan network
  9. click icon again and turn on wlan network
1 Like

Thanks - it seems that I have everything set up correctly. The pool of assignable IP addresses is between, and I have assigned the Pi a local IP address within that range. It also appears that this is the very same IP address my device is using. That said, I posted here after resetting the network connection so everything is working as it should. I’ll run some more diagnostics tomorrow when everything is not working…

The inevitable happened - I stopped being able to remotely interface with the pi using SSH, VNC Viewer, KDE connect etc. However, I ran the above commands and nothing had changed. The pi was using the same local ip address etc, and was connected to the internet. It’s very strange.

could you list the contents of these two files


cat /etc/ssh/ssh_config | eos-sendlog
cat /etc/ssh/sshd_config | eos-sendlog

ssh_config configures the ssh client
sshd_config configures the ssh server daemon


probably doing this is better

cat /etc/ssh/ssh_config | eos-sendlog
cat /etc/ssh/sshd_config | eos-sendlog
1 Like

That didn’t work - bear in mind I’m not using EOS on the raspberry pi, just on my laptop. I also did not post here in the expectation of getting EOS technical support, just to know if anyone has had this problem as a lot of people in the community have raspberry pis. I’ve searched high and low on the internet and it seems that a lot of pi users have this problem, but none of the solutions offered work. So this was really a last act of desperation.

The output of the first part of the command is:

cat /etc/ssh/ssh_config              

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Include /etc/ssh/ssh_config.d/*.conf

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

cat /etc/ssh/sshd_config              
#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

IPQoS cs0 cs0

No issues, just posting the content of these files is what @Pudge asked you to do. If there is a solution we’ll try to figure it out

Thanks - I posted it now. I think the “eos-sendlog” portion of the command was what failed (as I don’t have EOS on the laptop).

Yeah eos-sendlog just sends the output of cat to a pastebin which is easier to read. Just posting the contents of the file does the same