Re: Two RN516 units: missing shares after rsync

torer · ‎2013-12-02

Hello!

I have two RN516. When I installed the second unit, I did a rsync from the /data/* directory to the target RN516.

The problem now is that the one of the folders, /data/Repo, was initially only present on the source RN516 and so it got created on the target RN516.

It does not show up as a "share" in frontview. Thus, I am unable to enable SMB for it. If I try to create the share on the target RN516, frontview tells me that the directory already exists.

I did not notice this until I moved to unit to another office, so doing another sync over the internet is problematic.

Is there a way to manually register /data/Repo as a share through a SSH terminal window so that I can manage it through Frontview?

StephenB · ‎2013-12-02

The most direct path is to rename the folder to a temporary name, and create the share. Then move the data into the share with ssh (deleting the temporary folder after the move completes).

torer · ‎2013-12-02

Thanks for replying so quickly!

If that's the only way, I'll do that. The issue with that approach is that moving the files (3TB) into the newly created subvolume takes a very long time, and all I need is to make the directory available through SMB.

🙂

StephenB · ‎2013-12-02

You could also try renaming the folder, creating a share, and then renaming again so the original folder is again called "Repo".

I think that will work. I'd turn snapshots (e.g. "continuous protection") off initially. You might also need to reset file permissions when it is done.

EDIT- make sure that the current Repo folder is a btrfs subvolume before you try this.

torer · ‎2013-12-02

Yes, that works!

I tested this by creating a new folder with SSH,/data/TEST, and placed some files in the folder.

I then created a share called DUMMY, which I then renamed to TEST in FrontView and enabled SMB sharing. The share now shows files in the TEST folder, and the files in TEST were not overwritten by the rename.

I was left with /data/DUMMY, which I then successfully deleted using this command:

btrfs subvolume delete DUMMY

Thanks!

EDIT - did not see your note about checking if Repo is a btrfs subvolume first. It is not, nor is the TEST folder i created. But it works as far as enabling SMB sharing is concerned.

StephenB · ‎2013-12-02

torer wrote:
...did not see your note about checking if Repo is a btrfs subvolume first. It is not, nor is the TEST folder i created. But it works as far as enabling SMB sharing is concerned.

Then leave "continuous protection" disabled for that share.