The Class E Network

Getting the remote mount to show up in file systems is the goal.
Regarding that error - I checked and when I set up the share that reference the remote location, I accepted the default permissions which is root:root. (As follows)

Since these perm's come from the default create mask, I don't know why yours would be different..?? (Something unique to your install?) I'd have to ask you how the group "users" is involved in this? The group should be root.
____________________________________________________________________________

Also, check the relative Path on your remote mount. If it's anything else other than the following, OMV is attempting to create, or "write", a folder on the other end. This is something that you don't want to happen.

____________________________________________________________________________

It might be a good idea to leave the USB drive out of this, until you get at least one remote mount setup and Rsync job going between standard shares (local and remote). You know it will have special considerations.

That screen shot indicates that the remote mount itself is working.

Now, when you share it locally, what's the relative Path, of your remote mount? It should be "/" .

Zitat von geaves

The relative path comes out as Movies/ as it defaults to name given...however if just add / as a path (which I've just tried) same error!!
Error #0:exception 'OMV\Exception' with message 'Failed to set file group to 'users' for '/srv/2e983c87-02ad-4298-ba46-f6dd6c481a1c/Movies': ' in /usr/share/openmediavault/engined/rpc/sharemgmt.inc:339Stack trace:#0 [internal function]: OMVRpcServiceShareMgmt->set(Array, Array)#1 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)#2 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('set', Array, Array)#3 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('ShareMgmt', 'set', Array, Array, 1)#4 {main}

That's the full output of adding the remote to shared folders....TBH I'm stumped on this.

The relative path is "/". That's the root of the remount mount. Anything else will write a folder to the other end. (The dialog box indicates as much.)

Remember, I told you that you'd get an error because OMV will attempt write a folder (if the relative path is anything other than "/") and/or permissions to a drive that it thinks is local. When creating the remote share, leave the share permissions settings at the default, save it, close the error, and hit the "X" to close the dialog. Then see if the share exists.

(If the above doesn't work, I'll run through the process in a VM.)

Zitat von flmaxey

(If the above doesn't work, I'll run through the process in a VM.)

_____________________________________________

Thinking that there might be something different between using Windows or an OMV server as a remote mount source, I recreated what I told you in the post above, in a VM. It works.

Set the share with "/", save it, close the error, then close the dialog box with the "X". The local share, based on the remote mount, exists.

After establishing the remote share, I quickly set up a local Music share (below)

I set up a quick Rsync job, did a quick sync (that I terminated after some stuff replicated), setup a samba share, set all perm's wide open. "Music" from the OMV VM is on my net and I just listened to a song.

So, how'z it going with you?

Zitat von geaves

Houston I think we have lift off with a Dry run
Please wait, syncing </srv/2e983c87-02ad-4298-ba46-f6dd6c481a1c/> to </srv/dev-disk-by-label-HD-LXU3/OMV/Movies> ...

sending incremental file list

sent 216,469 bytes received 1,252 bytes 33,495.54 bytes/sec
total size is 425,599,277,740 speedup is 1,954,792.04 (DRY RUN)

Alles anzeigen

Good.

While it's very counter-intuitive:
If you went with Movies/ in the share relative path, a folder (Music) would be created on the remote file system. (That is if the remote mount user / password grants write access to the remote file system.) Unfortunately, if the newly created Music folder becomes the "root" of the remote mount, nothing is accomplished. The folder is empty.
(This is another reason why I maintain that giving the Remote Mount User anything more than "Read" access, to the remote mount itself, is a BAD idea in this use scenario.)

I was thinking about hitting up the Dev's regarding the Remote Mount default path choice, but what do I know? I'm a NOOB.

Zitat von geaves

Well the good is I've finally got this remote thing sorted just need to check your settings for the rsync....also got some IT to do at wife's school...I think they call it 'pro bono'
The bad is my wife's father passed away yesterday, he was in a hotel awaiting departure to the Guernsey...not good a lot has fallen to the wife as her sister fell out with their Dad, long story.....trying to keep her busy with school, but she's spent a lot of time on the phone, coroner, funeral directors, will executors, everyone is all over the country.

But this week end she's going to London with daughter to see her pen friend from the US, she's a pianist with the Cincinnati Symphony Orchestra, the Orchestra has just arrived in Edinburgh. So that should help, but at the moment she realises she's the only one that can get things sorted.

Sorry to hear about the wife's dad. Please pass on our regrets.
(Unfortunately, at certain ages and stages of life, the prior generation begins to pass. We, the wife and I, have already lost both parents.)

Oh, and sorry to hear about the 'pro bono' work as well.
Don't let that politician get you to do something that she can take credit for.

One last thing and I believe it's important. Before you go any farther, go to your primary server and insure that user / password combination that you're using to connect the remote share has only "read" access to the share.

You can do that, on the primary server, in the share's permissions. If you have any doubts about how to do that, work it out now. Why? It's fairly easy to fat finger or config an Rsycn job incorrectly. With certain options active and if your user has "write" access to the remote share, the contents of your primary server share can be DELETED.
(Again, not a good idea to give write access to a remote share.)

Zitat von geaves

Ok all the ones for Emby are set as guest, so on the primary server if I create a user Backup and give them read access only to those guest shares, then on the Pi set the user Backup as the user to login to the remote share?

Yes. That's what you want. (This should be part of the user / password duplication process between the primary and backup servers.)

The user "Backup" should be on both boxes with the same password. "Backup" should have read only access to the share on the primary server. I'd set "read" on the primary server share, in extended or "by name" ACL's as follows.
(BTW: what they're calling "Extra Options", at the bottom, is actually Linux default "basic" file and folder permissions. With the exception of scenarios like this one, where a specific user name needs a specific restriction, I like to stick to basic permissions.)

If you have "Read Only" set on the Samba share, that would do it, but I don't like relying on Samba for this purpose.

With the above on the source server, when setting up the Remote Mount instance, the user "Backup" with password will have read only.

I have a post "pending" for some reason, that shows a screen shot of share permissions. It might be awhile before the moderators clear it.

It can be done with Gparted. Stick the SD card into a slot on a PC, boot the PC with a Gparted CD, and resize the main partition. It's a good idea to do that as it helps with flash "wear leveling".

Zitat von flmaxey

I have a post "pending" for some reason, that shows a screen shot of share permissions. It might be awhile before the moderators clear it

Zitat von geaves

We must have reached or posting limit ....I seem to get errors regularly...just refresh the page and carry on

The longer the post, the more it has a chance to flagged as spam especially if it has links in it.