Drives not mounting properly in Drive_Manager

I am using a Rock64 as a file server with the system on a sd card and a HDD connected through USB used for storage.
The system worked when setup about a year ago. It was not used for months but was left powered on.
I tried logging in via SSH but the connection refused. I connected the board to HDMI and saw errors about the USB 3.0 port which prevented the system from booting. I switched to a different port and was able to login. After this I was able to connect drives to the USB 3.0 port and boot.

I had the userdata folder on the external HDD, which was mounted when first set up but now refuses to mount properly. I tried mounting the drive through drive_manager. The drive shows that it’s mounted in drive manager and /etc/fstab. noauto,x-systemd.automoun is set in the fstab. However, I am unable to access the share via FTP. Which I was able to previously do. When the system is rebooted the HDD is not mounted and displays the UUID instead of the mount name I assigned it in drive_manager. In fstab the mount is commented out after reboot. I mount the HDD through drive_manager and it automatically mounts to the name I assigned it. But the same errors persist and I am unable to access it through FTP. I am also unable to login to sonarr and radarr through the web interface.

Things I tried are,

  1. Switching from Samba to FTP
  2. Deleting the fstab entry, unmounting through drive_manager, deleting the residual mount folder in /mnt.
  3. 3 other drives.
  4. Different USB ports.
  5. Moving the userdata location from the system drive to the external drive and vice versa.

The logs are here

Many thanks for your report.

Let’s please start with using the external drive from scratch.

  1. If your dietpi_userdata are currently located at that drive, move it back to the internal drive.
  2. If the drive is currently mounted, use dietpi-drive_manager to unmount it.
  3. Verify that df and /etc/fstab do not contain it anymore (commented entries have no effect, not sure why we add them at all :thinking:).
  4. Unplug the drive and reboot the system so that all info about it is gone.

Then re-add the drive and debug each step:

  1. Attach the drive, check fdisk -l and lsblk whether it was detected correctly, in case partprobe /dev/sdX to make the kernel aware of its partition table.
  2. Mount it manually to a new mount point, mkdir /mnt/test && mount /dev/sdX1 /mnt/test, check whether you can access all data fine, dmesg doesn’t show any I/O errors etc.
  3. Then remount manually with the mount options we use in dietpi-drive_manager and retest, to rule out any issues with those. That depends on the file system type. Which one is it? I saw an NTFS in your logs?

Thanks for the troubleshooting suggestions. When initially set up I was using a NTFS drive but decided to switch to a different ext4 drive now.
During steps 1-3 I noticed df still shows the mount point, it is /mnt/StoreJet

Filesystem 1K-blocks Used Available Use% Mounted on
udev 427180 0 427180 0% /dev
tmpfs 100204 4120 96084 5% /run
/dev/mmcblk0p1 7595336 4294172 3202672 58% /
tmpfs 501016 20 500996 1% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 501016 0 501016 0% /sys/fs/cgroup
tmpfs 51200 8 51192 1% /var/log
tmpfs 1048576 4 1048572 1% /tmp
/dev/sda1 1921811248 940153124 883966068 52% /mnt/StoreJet

After unplugging the drive and rebooting df shows the mount point removed.
Manual mounting worked. I followed steps 1-4 to remount using dietpi-drive_manager and this also worked.
Perhaps unplugging the drive and rebooting is the critical step that I needed to resolve the issue. It is the only step I did not do in my solo troubleshooting.

There is one issue that remains, the /mnt/dietpi_userdata folder is empty. I believe it is because initially I had the dietpi_userdata on the external drive. The only folders that contained system data were the sonarr and radarr folders, which still remain on the external drive.

The issue with this is that I am unable to move the user data folder in any direction, in between the system sd card and the external HDD. Moving the user data folder to the external drive using drive manager shows as successful but soon after the userdata location defaults to the system sd card. I manually moved the sonarr and radarr folders to /mnt/dietpi_userdata but am still not able to access the services through the web interface, despite them showing as active in dietpi-services.

How can I restore radarr and sonarr?

The drive mounting logs are here

can you share the error logs pls

cat /var/log/radarr/radarr.txt
cat /var/log/sonarr/sonarr.txt

The logs are created but have no data written to them. They are 0 bytes. I opened with nano and dietpi-explorer to confirm.

root@DietPi:/var/log/radarr# ls -sh
total 0
0 logs.db  0 radarr.0.txt  0 radarr.txt

root@DietPi:/var/log/sonarr# ls -sh
total 0
0 logs.db  0 logs.db-shm  0 logs.db-wal  0 sonarr.txt

There are no sonarr and radarr folders in /mnt/dietpi_userdata but they are on the external drive

root@DietPi:/mnt/StoreJet/dietpi_userdata/radarr# ls -sh
total 296K
4.0K Backups        0 logs.db      4.0K MediaCover    4.0K
4.0K config.xml     0 logs.db-shm  4.0K
   0 logs           0 logs.db-wal  276K radarr.db

root@DietPi:/mnt/StoreJet/dietpi_userdata/sonarr# ls -sh
total 1.1M
4.0K Backups        0 logs.db-shm   32K nzbdrone.db-shm
4.0K config.xml     0 logs.db-wal  152K nzbdrone.db-wal
   0 logs        4.0K MediaCover   4.0K
   0 logs.db     892K nzbdrone.db

Did you tried to copy back the folder? They are needed to operate.

Copied now. Here are the logs

root@DietPi:~# cat /var/log/radarr/radarr.txt
2021-1-16 10:18:45.1|Info|Bootstrap|Starting Radarr - /opt/radarr/Radarr.dll - Version
2021-1-16 10:18:50.1|Info|AppFolderInfo|Data directory is being overridden to [/mnt/dietpi_userdata/radarr]
2021-1-16 10:18:50.3|Fatal|ConsoleApp|EPIC FAIL!

[v3.0.1.4259] NzbDrone.Common.Exceptions.RadarrStartupException: Radarr failed to start: AppFolder /mnt/dietpi_userdata/radarr is not writable
   at NzbDrone.Common.EnvironmentInfo.AppFolderFactory.Register() in D:\a\1\s\src\NzbDrone.Common\EnvironmentInfo\AppFolderFactory.cs:line 58
   at Radarr.Host.Bootstrap.Start(StartupContext startupContext, IUserAlert userAlert, Action`1 startCallback) in D:\a\1\s\src\NzbDrone.Host\Bootstrap.cs:line 33
   at NzbDrone.Console.ConsoleApp.Main(String[] args) in D:\a\1\s\src\NzbDrone.Console\ConsoleApp.cs:line 4

root@DietPi:~# cat /var/log/sonarr/sonarr.txt
21-1-16 10:18:40.5|Info|Bootstrap|Starting Sonarr - /opt/NzbDrone/NzbDrone.exe - Version
21-1-16 10:18:44.5|Info|AppFolderInfo|Data directory is being overridden to [/mnt/dietpi_userdata/sonarr]
21-1-16 10:18:44.6|Fatal|ConsoleApp|EPIC FAIL!

[v2.0.0.5344] NzbDrone.Common.Exceptions.SonarrStartupException: Sonarr failed to start: AppFolder /mnt/dietpi_userdata/sonarr is not writable
  at NzbDrone.Common.EnvironmentInfo.AppFolderFactory.Register () [0x0007b] in <faeb8209b6ff4c15aabf93dc8df43c9f>:0 
  at NzbDrone.Host.Bootstrap.Start (NzbDrone.Common.EnvironmentInfo.StartupContext startupContext, NzbDrone.Host.IUserAlert userAlert, System.Action`1[T] startCallback) [0x0005a] in <f9c7c3abe88b4bee9b1509c9a2ed54aa>:0 
  at NzbDrone.Console.ConsoleApp.Main (System.String[] args) [0x0002f] in <342de43622c54cdfafa06db962320038>:0

Now you have permission issues. How did you copied the folder? Did you used co -p to keep permission? Can you show content of user data folder ls -la /mnt/dietpi_userdata/

I used dietpi-explorer

root@DietPi:~# ls -la /mnt/dietpi_userdata/
total 16
drwxr-xr-x 4 root   root   4096 Jan 16 10:16 .
drwxr-xr-x 7 root   root   4096 Jan 15 16:36 ..
drwxr-xr-x 6 dietpi dietpi 4096 Jan 14 21:19 radarr
drwxr-xr-x 6 dietpi dietpi 4096 Jan 14 21:19 sonarr

Well it’s incorrect folder permission for both. Try

chown -R radarr /mnt/dietpi_userdata/radarr
chown -R sonarr /mnt/dietpi_userdata/sonarr

What do you mean with this? I would recommend to get the userdata successfully moved to that external drive, before using it for anything else. As long as something fails with this, there might be an issue with the system of the particular drive, which should be fixed first.

When you move userdata to an external drive, and no error prompt appeared, all data should be definitely located there. Then a symlink is created at the location of /mnt/dietpi_userdata, pointing to the new location, so that paths like /mnt/dietpi_userdata/sonarr remain valid. Check via:

ls -dl /mnt/dietpi_userdata
ls -l /mnt/dietpi_userdata /mnt/StoreJet/dietpi_userdata

The first should show you the symlink, the second should hence show you that those two locations share the same content.

but soon after the userdata location defaults to the system sd card.

I meant the userdata transfer using dietpi-drive_manager would complete with no errors but a few minutes later when opening dietpi-drive_manager the external drive would lose the mount point, display the UUID, be commented in the fstab, and the dietpi_userdata location would default to the sd card. During this I was also unable to access the drive using FTP. It was like the drive showed it was mounted when it really wasn’t.

After doing the troubleshooting steps MichaIng suggested and I was able to properly mount the external drive the userdata location transfer also completed without defaulting to the sd card moments later.

chown -R radarr /mnt/dietpi_userdata/radarr
chown -R sonarr /mnt/dietpi_userdata/sonarr

This worked to get both online and they are working properly now.
Thanks for all your help saved me the dread of having to reconfigure sonarr and radarr.

Great that it works now.

That the drive did mount first (allowing userdata transfer) and was not mounted afterwards, sounds like it could be a connection issue, probably due to insufficient power. Do you power your drives via dedicated PSU or via RPi USB power only? The latter case is at least known to be not reliable in cases, especially when the drive is not the only USB device attached.

dmesg | tail -10 could show voltage or I/O errors in that case.

I am using a 5V 3A psu on the Rock64 board. The 2.5" external drive is connected by USB power only to the Rock64. I am running the board headless and the external drive is the only thing attached.

To reduce heat and only passively cool the board I even switched to the conservative governor, 408MHz min 1200MHz max, throttle up 95%.
This is the output of dmesg | tail -10

root@DietPi:~# dmesg | tail -10
[    9.716652] rc rc1: dw_hdmi as /devices/platform/ff3c0000.hdmi/rc/rc1
[    9.717700] input: dw_hdmi as /devices/platform/ff3c0000.hdmi/rc/rc1/input2
[    9.837046] rk_gmac-dwmac ff540000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
[    9.850568] rk_gmac-dwmac ff540000.ethernet eth0: No Safety Features support found
[    9.851265] rk_gmac-dwmac ff540000.ethernet eth0: PTP not supported by HW
[    9.852383] rk_gmac-dwmac ff540000.ethernet eth0: configuring for phy/rgmii link mode
[   10.082665] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes
[   13.956240] rk_gmac-dwmac ff540000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   13.957044] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  341.830419] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

I can recommend the schedutil governor btw, it’s fast clocking up but as fast clocking down as well. Depending on usage it might even have lower average overall power consumption (=heat dissipation) while being more responsive as well.

In most cases it works with power over USB, but if any issue is faced, this would be the first thing I’d try to change. I’m not sure about max current of ROCK64 USB ports, but on RPi it’s e.g. 1A=5W shared by all USB ports, so taking into account fluctuations and peaks, this can be close for many SSDs, even more for HDDs. Just keep it in mind + have a look at dmesg | tail -10 when anything unexpected happens with the drive :wink:.