Share not showing in Frontview

[davidr1]

Ultra with OS6 6.7.5

I created a share in Frontview as per normal procedure.

As I don't run windows I only gave it nfs and rsync access with the normal ip addresses I use and the normal owner and group.

in ssh the folder attributes are the same as my other shares. I can also see its contents.

However it does not show in Frontview and it does not mount.

What can I do to resolve this please?

[StephenB · Accepted solution]

How about  btrfs subvol delete /data/Backups_Weekly_of_212/.snapshots

[JennC]

Hello davidr1,

Could you check if you will get the same results when you use another web browser? Perhaps you want to try creating a new share again leave SMB enabled also then check if you get the same results.

Regards,

[davidr1]

Thanks for replying JennC,

It happens in other browsers as well.

I can create and see new shares - already did this but did not configure with smb - none are.

Can I just delete it from /share using ssh or is it registered in a database of shares or something?

Also, if I do a factory reset using OS6 on the Ultra, which OS would it reset to?

[JennC]

Hello davidr1,

Yes, you can try

rmdir <sharename>

And then create a share

rn_nml [-v] -a share:/data/<sharename>

I believe this should show the share on admin page and SMB is enabled by default.

Regards,

[davidr1]

Thanks JennC.

If I factory reset the Ultra which uses OS6 would it reset to OS6?

I can't find any info on this.

[JennC]

Hello davidr1,

I think it will load the OS6 still since part of the upgrade from OS4 to OS6 is factory reset.

Regards,

[davidr1]

Many thanks JennC.

[Sandshark]

A legacy system running OS6 will act like a newer system when you do a factory default or an OS re-install -- it will re-install the currently loaded OS6 version.  The only thing that you have to do differently, and few need to do it at all, is USB recovery.

[davidr1]

Thanks Sandshark.

The share in /data/nameofshare will not delete with rm -rf nameofshare. It saus not empty but when I go into it there are only . (owned by me) and .. (owned by root).

So a reset is looking likely.

Don't I just need to Perform Factory Default in System Performance? If not I'll have to read up on USB recovery but I don't have Windows ...

[StephenB]

---

@davidr1 wrote:

The share in /data/nameofshare will not delete with rm -rf nameofshare. It says not empty but when I go into it there are only . (owned by me) and .. (owned by root).

This is when you are logged in as root with ssh?

Note that the [messed up] share should have been created as a btrfs subvolume, so you should check to see if the folder is a subvolume - and if it is you need to delete the subvolume.

---

@davidr1 wrote:

Thanks Sandshark.

Don't I just need to Perform Factory Default in System Performance? 

---

That will do a factory reset, I see no reason to do a USB recovery.

[davidr1]

Hi StephenB,

Yes, ssh as root.

btrfs fi show gives:

root@NASUltra:~# btrfs fi show
Label: '758b784e:root' uuid: d22cea30-6e62-41a0-a32d-3835cb3e9ff0
            Total devices 1 FS bytes used 524.09MiB
            devid 1 size 4.00GiB used 2.86GiB path /dev/md0

Label: '758b784e:data' uuid: a38d2022-e6de-4201-b0bd-20f9f4b33140
            Total devices 1 FS bytes used 300.89GiB
            devid 1 size 926.89GiB used 449.06GiB path /dev/md127

It is top level in the list produced by btrfs subvolume list /data

IID 1172 gen 199043 top level 5 path Backups_Weekly_of_212
ID 1173 gen 77940 top level 1172 path Backups_Weekly_of_212/.snapshots

[StephenB]

does btrfs subvol delete /data/Backups_Weekly_of_212 work?

[davidr1]

Same error - not empty:

root@NASUltra:# btrfs subvol delete /data/Backups_Weekly_of_212
Delete subvolume (no-commit): '/data/Backups_Weekly_of_212'
ERROR: cannot delete '/data/Backups_Weekly_of_212': Directory not empty

ls -alh
total 32K
drwxr-xr-x+ 1 david david 20 Aug 1 12:54 .
drwxr-xr-x 1 root root 432 Jul 28 11:19 ..

[StephenB · Accepted solution]

How about  btrfs subvol delete /data/Backups_Weekly_of_212/.snapshots

[davidr1]

Are there likely to be residual

Great! Many, many thanks, StephenB.

I had tried rm -rf Backups_Weekly_of_212/.snapshots but it did not work.

Is btrfs subvol delete .. the proper way to delete shares in /data in ssh?

Are there likely to be residual config files that need cleaning up?

[StephenB]

---

@davidr1 wrote:

I had tried rm -rf Backups_Weekly_of_212/.snapshots but it did not work.

Is btrfs subvol delete .. the proper way to delete shares in /data in ssh?

---

The proper way is to delete them from the admin web ui of course.  But in your case that didn't properly complete.

Each share is set up as it's own subvolume, so if you do need to delete them manually you should be using the BTRFS tools and not normal shell tools like rm. 

[davidr1]

Thanks StephenB.

Do you know all this about the NAS file structure through a manual, just analyzing the NAS or what? There are quite a few things that would be very useful to know - even though ssh is not supported and mistakes could brick the unit. For example, getting the BIOS settings - it would be very useful to see if there is an option to 'remember last state' if power fails (as the 212 [ARM?] does).

[StephenB]

Most of what I've learned comes from posts I've seen here (some from other blogs). 

I've never researched bios settings - I've just gone with the Netgear defaults on them.