Posts by sonofwatt

That makes sense. I'm going to add my docker and config files to the exclusions list.
What's weird about these errors is, this is a backup folder, so all the files are static. How do I get SnapRAID to accept these files? I want them to be synced and scrubbed, since they are a backup.

I'm also getting the following error messages from another SnapRAID email with the subject "Cron - SnapRAID - Scheduled diff."

Is this related to the script running multiple times?

There are 3 files in that dir. The contents match the 3 jobs that show up in OMV > Scheduled Jobs

Just the one for the script, and 2 others I created manually.

In case anyone ends up at this tread with the same issue like I just did, this article fixed the issue for me.

https://ugetfix.com/ask/how-to…de-0x80070035-on-windows/

It was fixed for me after the Modify Network Security Settings, and Enable NetBIOS steps.

I have email notifications on and got a string of 4 emails from my OMV server telling me the :SnapRAID SYNC Job finished". The task is scheduled for 3am.

The first email was 3:01, then 3:06, 3:10 and 3:22.

The content of the emails was slightly different with the "Cycle count" and "not met" numbers changing.

Email contents below.

Any ideas?

Please post back if that fixes it for you.
In my case I don't have IPv6 enabled on my router/gateway, but this is worth a try on the server if it works for you.

Hi Cubemin, thanks for the reply. Tried that but no luck.
Reading elsewhere online it looks like I may need to stop the quota service and then try changing ownership.
Also in another thread with a similar issue someone said the problem is that we're trying to change ownership of the root of the drive itself. Apparently you need to move down or up one level. Like change the ownership of the drive itself, or go 1 level from root into a folder and then recursively change ownership there.

Getting the following error when trying to use Reset Permissions or when trying to modify the shared folder ACLs.

This disk is from a previous OMV install.

Any ideas?

Error #0:
OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; chown --recursive root:users '/srv/dev-disk-by-uuid-8494346d-ac97-40a2-a38e-c043fb719bee/' 2>&1': chown: changing ownership of '/srv/dev-disk-by-uuid-8494346d-ac97-40a2-a38e-c043fb719bee/aquota.user': Operation not permitted
chown: changing ownership of '/srv/dev-disk-by-uuid-8494346d-ac97-40a2-a38e-c043fb719bee/aquota.group': Operation not permitted in /usr/share/openmediavault/engined/rpc/sharemgmt.inc:997
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(588): Engined\Rpc\ShareMgmt->Engined\Rpc\{closure}('/tmp/bgstatus0R...', '/tmp/bgoutputd9...')
#1 /usr/share/openmediavault/engined/rpc/sharemgmt.inc(1062): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure), NULL, Object(Closure))
#2 [internal function]: Engined\Rpc\ShareMgmt->setFileACL(Array, Array)
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('setFileACL', Array, Array)
#5 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('ShareMgmt', 'setFileACL', Array, Array, 1)
#6 {main}

Hi Nick,
Unfortunately no. I've since moved OMV5 to another system which I'm in the process of setting up. So far no errors like this.

Hi omvnj2323,
Wondering if you ever solved this issue. I've run into something similar.

Hi Guys,
Trying to get Plex working in Docker with hardware transcoding. Plex doesn't seem to see the capability.
I installed the 'intel-gpu-tools' package. When I run the 'intel_gpu_top' command, I get a "Couldn't Find Intel Graphics Card"

I also installed vainfo and libva-dev.

Looking in /dev/dri, only "by-path card0" is shown.

It seems like OMV didn't install any drivers.

This is the CPU and it does support QSV.
https://ark.intel.com/content/…cache-up-to-4-70-ghz.html

Any ideas?

Does anyone know a forum (maybe Debian specific), where I could post about this issue?
It's still happening often.

Quote from raulfg3

some times when share the entire disk this happhens, revise and post the full path of both folder (first (origin) and second (destination)), better if post the ownner and permision ( ls -la on the correct place of both folders) to revise it

Oh interesting.
Here are the paths and info. All the sub dirs have the same settings. It's the destination that has the issue.

Origin: /srv/dev-disk-by-id-ata-WDC_WD100EFAX-68LHPN0_1EJKAX4Z-part1/Media/Backups/Plex Media Server/Metadata

Info: drwxrwsrwx 6 root users 4096 Apr 28 04:59

Destination: /srv/dev-disk-by-id-ata-WDC_WD100EFAX-68LHPN0_JEK5R14N-part1/Config/Plex/Library/Application Support/Plex Media Server/Metadata

Info: drwxrwsrwx+ 6 root users 4096 Apr 28 05:03

Quote from Adoby

Update caches in Windows.

How do I do that? Did some googling but all that came up was stuff related to windows update cache.

I think so. I used the Reset Permissions tool in the OMV Shared Folders area to reset everything. No luck. Also I'm able to manually navigate down deep in the folder structure and view 100s of folders and files, so I do have the permissions.

Also as a double check my sanity I ran ls -lR | wc -l in both folders at the Debian CLI and the file counts match.

I'm in the process of moving a large number of files. In Windows 10 when viewing the files via SMB shares, the first folder shows over 100K files, and 44K folders, in then second folder just 1 file and 63 folders. When I browse deeper I can see there are definitely more than 63 folders. Both directories have the same ownership, they are the same file system ext4, and they are even the same model of HDD.

And when I do a diff with the options -rs, it shows everything is the same.

Any ideas?

This is getting out of control. "151 to 200 of many"...

I can also rule out Plex being an issue. It wasn't running while the last 100 or so alerts came in.

Please, any help is hugely appreciated.

Unfortunately running that command didn't help in my situation. Cockpit took 3 tries to load properly.

But I'm also having issues with nginx elsewhere, so who knows.

Monitoring restart -- Connection failed nginx

Quote from Agricola

1. What kind of hardware do you have?
2. Do you run Nextcloud or Plex on it?

1. I have a Asus server grade 1U enclosure.

2. No to Nextcloud, although I'm thinking of deploying it. Yes to Plex, but it's running in a docker container.

This is continuing to happen about once a week, but at random. Nothing for 2 weeks, then twice within the last 16 hours.
As with last time the last time time the final messages were 2 emails about the 'Monitoring restart' failing. But when I check the service status service nginx status it shows as up and running. Albeit as of the time of the last 'Monitoring alert -- Connection succeeded' email.

Did you just run this at the command line?

What is omv-salt?