from
/etc/openmediavault/config.xml
you mean
omv-extras plugins - porting progress to OMV 6.x (done)
- ryecoaaron
- Geschlossen
-
-
Almost there.. now I could mount the disks also I add them in snapraid
..but I cannot see the paths in mergerfs...
and cannot delete the shared folder to recreate it. -
I cannot see the paths in mergerfs
I don't know what this means. You either type the paths in or pick shared folders. If you are trying to share full disks, get the path from the Mount Point column in the Filesystems tab.
-
all done.
-
i think the scheduled diff button in snapraid plugin does not work as intented. it just takes me to the screen of schedules jobs, without the actual command prefilled.
-
i think the scheduled diff button in snapraid plugin does not work as intented. it just takes me to the screen of schedules jobs, without the actual command prefilled.
There is no way to prefill the command. So, it is working as I currently intended. I will still debating on whether I wanted to work on ways to improve it. Until then, use /usr/sbin/omv-snapraid-diff as the command. This new web interface is a lot of work porting and you are now seeing some things I am struggling to port.
-
i understand. maybe the plugin could create a cronjob disabled by default during the installation and the user would have the option to enable/modify it...?
-
maybe the plugin could create a cronjob disabled by default during the installation and the user would have the option to enable/modify it...?
That is what it used to do. I can't do that the same way on omv 6.x. If i decide to improve it (not a high priority), it will have to be all new code. I'm not even done porting the plugins.
-
no worries, of course these are low priority things. (i get the feeling the ideas/suggestions on this forum are met with a backlash and a "then do it yourself" attitude...)
-
(i get the feeling the ideas/suggestions on this forum are met with a backlash and a "then do it yourself" attitude...)
I think that is very wrong. Most plugins I have written are due to ideas/suggestions because I do not use them. When I am struggling to port the plugins to a new version, I am probably not super receptive to new ideas at that time.
-
Yeah, I also face the issue with File name too long with systemd mount units. 255 seems like a weird limit for the What field in systemd mount units (ah well)
Interestingly enough, I tried a manual fstab entry and it works and does not have any length limitations.
I read around as much as possible, was the reason to switch to systemd mount units to make mount dependencies easier to manage and in general move to systemd?
Also noticed, it does not delete the symlink created in /etc/systemd/system/multi-user.target.wants when you delete the mergerfs entry in GUI (and run apply configurations).
In the meantime, I'll try this out:
So basically move everything to "/everything" and go with "/srv/dev-disk-by-uuid-*/everything"? Got it, thank you.
Thank you all for the discussions and suggestions!
Hopefully our collective brainstorming can come up with a solution!
-
In the meantime, I'll try this out:
Thank you all for the discussions and suggestions!
Hopefully our collective brainstorming can come up with a solution!
That's a viable solution, but I'll actually go with CrowleyAJ 's solution:
ZitatAlles anzeigenYou can use character classes in square brackets:
These are my drives:
dev-disk-by-uuid-16578662-b8be-4ded-a43b-bed36de32f6b
dev-disk-by-uuid-468c061d-4943-44db-9d6e-7efad6fcad8f
dev-disk-by-uuid-b000e4b4-0947-4345-b0e3-010472ab7c5b
dev-disk-by-uuid-b31200c5-2906-4a2e-b8ed-bc428ef76da2
dev-disk-by-uuid-bc99bd8a-854c-426a-96e7-a6187ead074a
dev-disk-by-uuid-e1695f6d-370d-4ac2-aa49-bb3f9ed5bd75
If I only want to include the first four I use this expression:
/srv/dev-disk-by-uuid-[14b][603]*/
This will include all drives which UUIDs start with 1, 4 or b and have a 6, 0 or 3 in the second position, which matches the first four UUIDs, and only those.
-
That's a viable solution, but I'll actually go with CrowleyAJ 's solution:
I was thinking that too but was worried about addition of newer drives that could match the expression and dynamically being added to the pool. Instead I was leaning more towards an explicit method of either adding via mergerfs (but cannot due to systemd mount 255 limit) or creating the necessary folder (eg: /everything) that it needs before including it into the pool.
Actually, I'm going to do a mix of both, even more narrow than themselves alone:
Code/srv/dev-disk-by-uuid-[14b][603]*/everything -
I was thinking that too but was worried about addition of newer drives that could match the expression and dynamically being added to the pool. Instead I was leaning more towards an explicit method of either adding via mergerfs (but cannot due to systemd mount 255 limit) or creating the necessary folder (eg: /everything) that it needs before including it into the pool.
Actually, I'm going to do a mix of both, even more narrow than themselves alone:
Code/srv/dev-disk-by-uuid-[14b][603]*/everythingI've gotten so fond of symlinks I've ditched UUID's completely (unless I absolutely have to use it). They set up in seconds.. you can put them in a single centralized location (I have all mine under /NAS).. Obviously that doesn't matter much with nfs/smb, etc.. but when needing access to my files at the command line level, or writing docker-compose files.. it's WAY easier.
-
I've gotten so fond of symlinks I've ditched UUID's completely (unless I absolutely have to use it). They set up in seconds.. you can put them in a single centralized location (I have all mine under /NAS).. Obviously that doesn't matter much with nfs/smb, etc.. but when needing access to my files at the command line level, or writing docker-compose files.. it's WAY easier.
I think that would not work here.
-
I think that would not work here.
with Plugins, correct... but with most of the plugins, they use shared folder locations where you just select a shared folder, rather than having to use it's path (or at least they did.. I don't really use plugins anymore other than nfs).
I like symlinks for docker-compose/stacks. I pretty much don't even have to look at my paths while writing a stack as I know exactly where everything is supposed to go.. and the stack will just create the folders as needed when it's deployed.
-
I tried a manual fstab entry and it works and does not have any length limitations.
True but nothing I can control. Since systemd converted fstab entries to mounts, I don't understand why fstab entries don't have the limit.
was the reason to switch to systemd mount units to make mount dependencies easier to manage and in general move to systemd?
Mount dependency issues was the main reason why I changed the plugin.
Also noticed, it does not delete the symlink created in /etc/systemd/system/multi-user.target.wants when you delete the mergerfs entry in GUI (and run apply configurations).
I will add code to clean those up by disabling the mount before deleting it.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!