Since a week I am not able to access Nextcloud anymore. Today I tried to trouwbleshoot the issue. ReForis (version 1.5.0) notifies that it “Can’t mount device /dev/sda as /srv for data storage”. After rebooting the problem persists. When I ssh into my Turris Omnia router and try to manually mount the device, via the command mount /dev/sda /srv it yields “mount: /srv: mount(2) system call failed: Value too large for data type.”. Also that error message persists after reboot.
I did not change or install anything on my router recently except for the automatic updates of Turris/ReForis and except for regular synchronization of files, calendar, tasks and contacts via the Nextcloud-interface.
I am on Turris OS version 7.0.3 (branch HBS), Kernel version 5.15.148. Nextcloud (version 24.0.9-5) is installed on a 12 TB external HDD, btrfs-formatted.
On another (64 bit) linux computer I am able to mount the volume without any problem. Can the error message have something to do with the Turris Omnia hardware still being 32-bit? If I search the internet for this error message, I find a lot of references mentioning the 32-bit to 64 bit difference.
The 32-bit hardware is also the reason why the Nextcloud version officially provided with Turris OS is still version 24 (24.0.9-5), while the lastest Nextcloud is version 30. See: Future of Nextcloud in Turris OS
That would be strange, since from your initial description it used to work alright. I can’t imagine a device and OS partitioning and or formatting a drive in a way that the device can’t access it anymore.
The Nextcloud 32bit/64bit is more a software build and compatibility issue. Your error message has nothing to do with Nextcloud or any other application software. It’s the OS who can’t mount it.
Did you perform some tests (e.g. chkdsk) on the PC with the drive attached?
I checked the HDD from another linux computer using the command btrfs check --readonly /dev/sdc. The result (after seven rounds of checking: no error found (6272955879424 bytes used). The disk is in order. Later today, when I am home again, I will reattach the drive to the Turris Router and check whether or not it is now able to mount the drive…
At this point, I would probably do a backup of the files on the drive, while it is attached on the PC.
Re-connect it to the Turris Omnia, let it re-partition and format on the Omnia itself. Do some tests (unmount, remount, reboot, etc.) and if everything looks good, restore the files from the PC.
Thanks, there indeed seems to be something wrong with the disk, despite the results of the btrfs check command. After reattaching the drive to the Turris Omnia, a mounting command on the drive returns a (different than previous) error message: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error, while a different disk (backup-mirror of the original disk) mounts without any problem. Fortunately (and strangely enough) both drives still mount without any problem on the other linux computer, and I am now updating the backup (mirror).