My share is gone.

[ressof]

mke2fs -n /dev/sda8

Code: Select all

mke2fs 1.42.11 (09-Jul-2014)
Creating filesystem with 487653137 4k blocks and 121913344 inodes
Filesystem UUID: b0e009dc-2076-43ab-b82d-8c6fa979151b
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848


tune2fs -l /dev/sda8

Code: Select all

tune2fs 1.42.11 (09-Jul-2014)
tune2fs: Bad magic number in super-block while trying to open /dev/sda8
Couldn't find valid filesystem superblock.

e2fsck /dev/sda8

Code: Select all

e2fsck 1.42.11 (09-Jul-2014)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sda8

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>


[Jocko]

So you need to use a backup super block

Currently these are

Code: Select all

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848

try with the first

Code: Select all

e2fsck -y -b 32768 /dev/sda8

if it fails use the following,...


---edit---
If you have a big partition, and you succeed to use another superblock, e2fsck will take a long time to scan the fs.

After you should be able to mount sda8

[ressof]

This command worked

Code: Select all

e2fsck -y -b 819200 /dev/sda8

And when I rebooted the share was there. Thank you.

But how should i fix the nobody problem. Seems that a lot of files is owned by nobody.

[fvdw]

This command worked

Code: Select all

e2fsck -y -b 819200 /dev/sda8

And when I rebooted the share was there. Thank you.

But how should i fix the nobody problem. Seems that a lot of files is owned by nobody.

glad to hear your problem is solved with the lost shares

About "nobody". This is not a problem it by design. That is the user under which amongst others the webserver does its jobs. When those script creates folders o files it will be owned by "nobody"

[Jocko]

should the owner and group of /rw_fs be nobody:nogroup

I thhink there is some thing about the groups settings. Could you post the outputs of

Code: Select all

 ls -l /etc/group
ls -l /rw_fs/tmp/etc/group
ls -ld /rw_fs

And I ask again what version do you use? (because if I remember well in an old version we fixed a group issue)

[ressof]

ls -l /etc/group

Code: Select all

lrwxrwxrwx  1 root root 20 2015-01-10 08:42 /etc/group -> /rw_fs/tmp/etc/group

ls -l /rw_fs/tmp/etc/group

Code: Select all

-rw-r--r--  1 root 0 0 2015-01-10 14:56 /rw_fs/tmp/etc/group

ls -ld /rw_fs

Code: Select all

drwxrwxrwx  8 nobody 99 4096 2015-01-10 08:42 /rw_fs

And I use version 16.0 without patches.

[Jocko]

I found again how you can get 'nobody:nogroup' with some files.

Previously, we did not set a group with the apache server and then the files created by httpd have the default guid 65534 (<-> nogroup) for example, if you use webdav feature.
Currently we know only one case that causes issue: rsync fails to set the owner settings when it synchronizes two folders but maybe btsync has the same issue according with your first post.

Except for this case, you can keep this owner settings however you can use this command to remove this default group:

Code: Select all

chgrp -R  99 /share/1000/yoursharename

At least with version 16.0, this issue exists no longer and it is why you have now

drwxrwxrwx 8 nobody 99 4096 2015-01-10 08:42 /rw_fs

But I see that the nobody group seems not to be fully set. You should get with the previous sample

drwxrwxrwx 8 nobody nobody 4096 2015-01-10 08:42 /rw_fs

Can you see if you have the line

Code: Select all

nobody:x:99:

after the root line in the output

Code: Select all

cat /rw_fs/tmp/etc/group

[Jocko]

You have an issue with your group file :scratch

ls -l /rw_fs/tmp/etc/group

Code: Select all

-rw-r--r--  1 root 0 0 2015-01-10 14:56 /rw_fs/tmp/etc/group

So you have an empty group file!

To find the issue we need to use the debug mode. Enable it with the url

Code: Select all

http://yournasname/.status/nas-status.php

.

and post the /boot.log file after rebooting your nas

[ressof]

its not empty now. when I run

ls -l /rw_fs/tmp/etc/group

I get this now

Code: Select all

-rw-r--r--  1 root root 167 2015-01-11 14:28 /rw_fs/tmp/etc/group

and it has this line

nobody:x:99:

I have renamed the files from log to zip to be able to attach them, just rename again

[Jocko]

Hi ressof,

So your last issue seems to be fixed. :thumbup

I assumed that twice booting has restored some permissions in /rw_fs