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,
Switching from Samba to FTP
Deleting the fstab entry, unmounting through drive_manager, deleting the residual mount folder in /mnt.
3 other drives.
Different USB ports.
Moving the userdata location from the system drive to the external drive and vice versa.
Let’s please start with using the external drive from scratch.
If your dietpi_userdata are currently located at that drive, move it back to the internal drive.
If the drive is currently mounted, use dietpi-drive_manager to unmount it.
Verify that df and /etc/fstab do not contain it anymore (commented entries have no effect, not sure why we add them at all ).
Unplug the drive and reboot the system so that all info about it is gone.
Then re-add the drive and debug each step:
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.
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.
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
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.
root@DietPi:~# cat /var/log/radarr/radarr.txt
2021-1-16 10:18:45.1|Info|Bootstrap|Starting Radarr - /opt/radarr/Radarr.dll - Version 3.0.1.4259
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 2.0.0.5344
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/
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.
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.
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 .
).
.