HDD dodgy?

Basic Help & Support Hardware
1

Hi,
I am having trouble getting my new lappy Nextcloud client sync with RPi Nextcloud ‘Box’ back up and running
All was fine on the old ASUS

I have two large folders I sync (350 GB, 100K items)

I first copy -pr the files from my lappy to the Nextcloud HDD and then I can access the files via web on my Nextcloud but sync via the Nextcloud-client on the lappy to the RPi Nextcloud box fails during the ‘checking for changes’ stage, for both, separate syncs, with a loss of connection to the box, and then crash of box.
This happens in Archlabs and Win 11, and not at the same files

I have reformatted and reinstalled all on both the RPi (Ubuntu server plus Nextcloud Snap) SD card side (on various, new cards) and the data on the (original Nextcloud Box WDLabs 1TB HDD)

Like I said, I can access the disk on the Nextcloud web interface, all is working in terms of connections, ports etc etc

Its just syncing that doesnt work

so, getting to the point (sorry), the WDLabs HDD has been running since 2017, so I thought maybe it was a problem(s) on this disk

So I looked up how to check a disk and found this

No errors, except for this:


leigh@T16-AL ~ % sudo fsck /dev/sda       
fsck from util-linux 2.38.1
e2fsck 1.46.6 (1-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/sda contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1953458175 sectors, extended partition table (last)' data

I tried the two suggestions it made but no success

so I researched more and found this suggestion, but again no success:

leigh@T16-AL ~ % sudo mke2fs -n /dev/sda 
mke2fs 1.46.6 (1-Feb-2023)
/dev/sda contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1953458175 sectors, extended partition table (last)' data
Proceed anyway? (y,N) y
Creating filesystem with 244182272 4k blocks and 61046784 inodes
Filesystem UUID: 313c3bfb-bf23-4ce7-b1c4-36e1feca189e
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

leigh@T16-AL ~ % sudo e2fsck -b 32768 /dev/sda
e2fsck 1.46.6 (1-Feb-2023)
e2fsck: Bad magic number in super-block while trying to open /dev/sda

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/sda contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1953458175 sectors, extended partition table (last)' data
leigh@T16-AL ~ % sudo e2fsck -b 214990848 /dev/sda
e2fsck 1.46.6 (1-Feb-2023)
e2fsck: Invalid argument while trying to open /dev/sda

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Its a ext4 linux disk (I just reformatted as ext4, so no surprises there) for sure as Gparted & gnome-disks tell me and:

leigh@T16-AL ~ % lsblk                    
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931.5G  0 disk 
└─sda1        8:1    0 931.5G  0 part 
nvme0n1     259:0    0   1.9T  0 disk 
├─nvme0n1p1 259:1    0  1022M  0 part /boot
├─nvme0n1p2 259:2    0    16M  0 part 
├─nvme0n1p3 259:3    0   300G  0 part 
├─nvme0n1p4 259:4    0     2G  0 part 
├─nvme0n1p5 259:5    0   100G  0 part /
├─nvme0n1p6 259:6    0    10G  0 part [SWAP]
├─nvme0n1p7 259:7    0   850G  0 part /run/media/leigh/Documents
└─nvme0n1p8 259:8    0 644.8G  0 part /run/media/leigh/Work

Check and repair sda1 with gparted gives no errors

Is it that I should be using fsck only on the partition sda1 and not the disk sda?

sda gives no errors:

leigh@T16-AL ~ % sudo fsck /dev/sda1     
[sudo] password for leigh: 
fsck from util-linux 2.38.1
e2fsck 1.46.6 (1-Feb-2023)
NCdisk: clean, 227808/61046784 files, 165237048/244181760 blocks

and:

leigh@T16-AL ~ % sudo badblocks -v /dev/sda
Checking blocks 0 to 976729087
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

And

leigh@T16-AL ~ % sudo smartctl -H /dev/sda 
[sudo] password for leigh: 
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.15.91-4-lts] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

So does it look like my disk is OK, despite its age?

2

Check that ‘user’ permissions for that drive includes rw in /etc/fstab.

4 Likes
3

Cheers @GreenMartian

I checked, it was defaults which I think includes rw, but to be sure I changed to rw,defaults

But, still the same problem, and I checked and I can read and write files to that external HDD in the web app of Nextcloud (so presume its got rw working)

4

External drive is healthy. Try the LTS kernel if your drive is 6 years old.

1 Like
5

It seems that the Ubuntu server is LTS:

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 5.15.0-1024-raspi #26-Ubuntu SMP PREEMPT Wed Jan 18 15:29:53 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

It must be a Nextcloud problem rather than the disk I guess

Ho hum.

1 Like
6

Well,

I was moving files around on the Nextcloud Box disk via the web interface and I noticed all files and folders were easy to move up a folder, except for two specific sub-folders - one in each of my two sync folders, which kept failing to move.

Anyway, to cut a long story short - it was the .htaccess files! (in a backup of a website and a MATLAB SIMULINK screenshot folder)

It turns out that Nextcloud syncing of these is suppressed as Apache might take them as instructions (you can tell my level of understanding is real deep here)

So, I have zipped those folders (safer than just allowing .htaccess file sync, apparently) and am now cp -rp ing my lappy files to the Nextcloud hard disk (currently plugged into said lappy) again, ready to then see if my RPi Nextcloud Box will then rise from the ashes once more!

I am hopeful, as I can now remember having to do this before - but I didnt write it down and so it was lost in the mists of time (Like what I did half an hour ago already is :roll_eyes:).

Thanks for your help @GreenMartian - I learnt some new stuff from you, and looks like you were right about disk being OK

Now touching wood that I dont have to edit this post when the cp file copy finally finishes and I can try the sync again

7

Consider yourself the first to ever say that @leigh! :smile:

Sometimes, it’s the most simple solution.

8

I am sure that is not true, but will take any accolade I can :rofl:

Bugger and Arse!
Me and my big mouth :rofl:

Well, its still not working, but I am now able to say that it is not a problem with the disk, nor with the Nextcloud installation.

I split the Nextcloud syncs up into separate subfolders of the overall folders (‘Work’ & ‘Leighs Documents’) and I am finding that some folders are syncing fine, but others not.

So at least I now know what the problem is which makes finding a solution a bit easier

9

With a bucket of folders, so to speak … some in the bucket is syncing and some are not. The drive & the client (Nextcloud) are attempting to do what you want them to do.

You may have residual folder/file write permission issues with some of those folders/files in your “Work” repo.

You could try either of the two (obviously, change your user & location detail) …

sudo chown -R leigh@leigh /home/Work

sudo chmod -R 777 /home/Work
1 Like
10

I have to do the chown to give root ownership on the RPi - but hadnt done it properly so that solved some problems :+1:

I’m only use chmod 777 to be able to delete problematic folders, I’m a bit scared of that one

reminds me of Attila the Stockbroker’s 1992 Album:

Attila The Stockbroker – 668: Neighbour Of The Beast