Beiträge von baggar11

I thought I had read about it not being ideal to put content files on parity disks because of the potential for both to eat up space. Especially with large amounts of small files. Oh well, my array is off on a full sync now. 24 hours remaining...

Well, I guess it may be that snapraid requires a minimum of 3 content files. Didn't know that and wasn't able to find it in the snapraid docs. I had a response over at the snapraid subreddit and was told so. So, I'll trust the advice, add a content file to one of the parity disks and be done with it. Thanks again for your help.

That sounds like what may be happening then. Although I searched the /etc/openmediavault/config.xml file for the snapraid config. It looked to mirror the 4 drive config. Assuming that config.xml file is the OMV dB.

As far as removing the old array, I used the plugin for some portions of the removal process. Then manually deleted the content and parity files on the FS via CLI before using the plugin to create the new configuration.

It's looking more and more like I'll have to add content files to the parity disks as you suggest.

Just seems strange that I blew away all previous snapraid config, including the content and parity files, and only have the new /etc/snapraid.conf file that defines the new 4 drive array. Why and how is snapraid still pulling configuration from the previous 5 drive array. Thanks for replying.

Had a previous snapraid array with 5 drives. 3 were data + content and 2 were parity. I've since migrated to 4 larger drives. 2 being data + content and 2 for parity. I've deleted all snapraid.parity, snapraid.2-parity as well as all snpraid.content files.

When I try to do a full sync with the new drives, I get the above error about needing 3 content files. /etc/snapraid.conf lists the new drive configuration(2 data/content + 2 parity) and no 3rd content file. What gives? Is OMV hanging onto the previous snapraid config somewhere? Anyone run into this?

Just to add to this, I ran through some more testing. With a delete threshold setting of 1, if you have 1 file that has been deleted, the script will still run a sync!

There are differences! SnapRAID DIFF finished – Thu Mar 23 08:21:08 PDT 2017 ----------------------------------------
Changes detected [A-0,D-1,M-0,C-0,U-0] -> deleted files (1) is below threshold (1). Running SYNC Command SnapRAID SYNC Job started – Thu Mar 23 08:21:08 PDT 2017

But if you have 2 files that have been removed with a delete threshold of 1, the sync does stop properly.

There are differences! SnapRAID DIFF finished – Thu Mar 23 08:28:09 PDT 2017 ----------------------------------------
Number of deleted files (2) exceeded threshold (1). NOT proceeding with sync job. Please run sync manually if this is not an error condition

I think in the short term, this doesn't pose much of a problem. But it would be great to have a mechanism in place that completely stops syncs if there are any deleted files.

I'm in the same boat! Just started using Snapraid and started playing around with the omv-snapraid-diff script to help automate unsupervised syncing. I noticed the same message in my email notification about delete threshold being disabled. It appears that after running through a small test, 0 actually means disabled as stated in the email.

TEST:
1. deleted a couple test files
2. verified that 'snapraid diff' produced deleted files in output
3. scheduled the omv-snapraid-diff to run the next minute and then waited

The email and the log files both showed that the sync took place even though there were more than 0 deleted files.

There are differences! SnapRAID DIFF finished – Wed Mar 22 15:22:08 PDT 2017 ---------------------------------------- Changes detected [A-0,D-2,M-0,C-0,U-0] -> there are deleted files (2) but delete threshold (0) is disabled. Running SYNC Command SnapRAID SYNC Job started – Wed Mar 22 15:22:08 PDT 2017

[2017-03-22 15:22:08] omv-snapraid-diff: INFO: 'SUMMARY of changes since last sync:'
[2017-03-22 15:22:08] omv-snapraid-diff: INFO: 'Added: [0] - Deleted: [2] - Moved: [0] - Copied: [0] - Updated: [0]'
[2017-03-22 15:22:08] omv-snapraid-diff: INFO: 'Changes detected [A-0,D-2,M-0,C-0,U-0] -> there are deleted files (2) but delete threshold (0) is disabled. Running SYNC Command.'
[2017-03-22 15:22:08] omv-snapraid-diff: INFO: 'SnapRAID SYNC Job started'

So it's probably best to set that value to 1 and hope that the 1 file isn't one that you will miss...

Ha! Figures, after I posted, I tried to recreate my issues and couldn't. Then I noticed that bug#0000830 seems to be what fixed it in v0.5.8. What is the sambashare group for anyways?

Ok, I was able to get this figured out. I think 1 of 2 things happened.

1. I didn't have my user with a valid /bin/bash login set.

and/or

2. I didn't have my user apart of the "users" group. I thought the "sambashare" group was for the smb/cifs access.

Hopefully that helps you out assapar. Also, it's been a while since I had to mess with it, but I believe when Vista and 7 came out, they aren't able to hop onto shares that don't have usernames/passwords set. I can't remember if there was a work around or it was fixed. Good luck!

I tried it using ACLs, no ACLs and giving explicit user permissions. I never tried adding a user to a group and giving access to the group if that's what you mean. Although the OP might have.

With just user permissions to the share, the best I could get was viewability, but no write access.

Is there something you're referring too in there?

1. I read the changelog
2. It was a fresh install
3. Again, fresh install
4. I wouldn't be able to even access the smb share without hitting the "apply settings" button.
6. SMB/CIFS support isn't a plugin issue
7. Not developing...

I think SMB/CIFS is broken in both 0.5.6 and 0.5.7. I'm having the same issues. The furthest I could get was to pull up the share, but nothing was writeable. I repeated the same steps on 0.4.36 and it worked flawlessly.