No files visible via mountpoint

[ds4a]

I have been using s3backer very successfully for sometime in conjunction with Nextcloud (v20, on Ubuntu 18.04) and AWS S3. After the recent S3 issues that many experienced (netflix, etc) I was also unable to access files as the mountpoint was unavailable (due to the fact AWS S3 was experiencing issues). Once the AWS S3 issue was resolved I find myself with the following problem.

I can mount the s3backer FS. Once mounted the filesystem is empty? I can see all of the 'blocks' in my S3 console, it reports that there are over 2.3Tb in use. I have no way to view any file via the mountpoint for s3backer or via the S3 storage console (all you can see is the s3backer blocks). Is there any way to recover my files? Is there some kind of s3backer FS rescan?

[archiecobbs]

That's odd...

Apologies if this is too pedantic, but you are remembering that there are two filesystems that have to be mounted, right? First, you get s3backer running. Then you mount a "regular" filesystem using a loopback mount on top of the file that s3backer creates.

Also, did you try running fsck(8) on the file that s3backer creates?

[ds4a]

Hi Archie,

Thanks for the reply. Not too pedantic at all always good to check the basics, which I can confirm have been done. I'm going to run fsck now and I'll feedback.

[ds4a]

Hi, I can see my s3backer FS file: drwxr-xr-x 2 root root 0 Jan 8 17:15 . drwxr-xr-x 4 root root 4096 Jun 20 2019 .. -rw------- 1 root root 5497558138880 Jan 8 17:15 s3backerFS -r--r--r-- 1 root root 1428 Jan 8 17:51 stats

but I get this when I run fsck:

fsck s3backerFS fsck from util-linux 2.31.1 Usage: fsck.ext4 [-panyrcdfktvDFV] [-b superblock] [-B blocksize] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] [-z undo_file] device

Emergency help: -p Automatic repair (no questions) -n Make no changes to the filesystem -y Assume "yes" to all questions -c Check for bad blocks and add them to the badblock list -f Force checking even if filesystem is marked clean -v Be verbose -b superblock Use alternative superblock -B blocksize Force blocksize when looking for superblock -j external_journal Set location of the external journal -l bad_blocks_file Add to badblocks list -L bad_blocks_file Set badblocks list -z undo_file Create an undo file

[ds4a]

OK, I have now specified the full and correct path for fsck and get this:

fsck /mnt/nnnn/data/wasabi/nnnn-data-primarymount/s3backerFS fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) /mnt/nnnn/data/wasabi/nnnn-data-primarymount/s3backerFS: clean, 495/167772160 files, 10876343/1342177280 blocks

[ds4a]

I then ran the below command, but it only seems to report <500 files, there should be >1,000,000:

fsck -vf /mnt/plusdrive/data/wasabi/plusdrive-data-primarymount/s3backerFS fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information

     495 inodes used (0.00%, out of 167772160)
       3 non-contiguous files (0.6%)
       0 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 485/2
10876343 blocks used (0.81%, out of 1342177280)
       0 bad blocks
       1 large file

     200 regular files
     286 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
       0 symbolic links (0 fast symbolic links)
       0 sockets

---

     486 files

[archiecobbs]

s3backer doesn't know anything about ext4 files, it just knows about filesystem blocks. So it's not clear what might have caused files in the ext4 filesystem to disappear.

It doesn't look like the filesystem blocks got corrupted, based on fsck running successfully without reporting problems.

Is it possible there is some other cause that's not related to s3backer itself?

[archiecobbs]

Closing old issue. Feel free to add more comments if there is new information.