piyper

Just a comment, Out of the choices above, most either have a process for getting around the deficiency or could be accomplished by the work of our community developers as an app or plugin. It is always nice to know what is wanted and what cool ideas people have, but it would also be nice if priority was given to the things that only the folks at Unraid can do and do not have an easy work around.

I am working a utility that connects to multiple databases. Could you please some data database driver extensions ? pdo_odbc.so odbc.so if there are specific ones for MS SQL Server or Oracle, I wouldn't mind those, but I think ODBC would cover those. Thank you!

Assuming your network type on the docker is bridged, you probably want to stay away from using 80 or 443 to avoid any conflicts with unraid itself. You could use 443 and 80 if you like, but you should then setup the docker to have a different IP address than your unraid server. To do this, you have to create a custom docker network, then choose that as your network type, you can then assign a new IP address. Make sure it is not within the range of your DHCP server IP range if you are using an IP within the same subnet. You would use the "docker network create SOMENAME" command to create a custom network, then you can specify a different IP in your docker when you select that network type. Steps: 1) Check that in your docker settings (settings->docker->advanced view) you have "Preserve user defined networks" set to yes. 2) Create custom docker network 3) select that custom network in your docker container settings 4) assign an IP (that will not conflict with your DHCP range) 5) set the container ports to be 80 and 443 Your web app should now respond on the browser default ports at that new IP address.

Just a suggestion on the VM selection, I pulled this from my script if you are interested, just makes the selection easier. menu.txt

Thank you for this!, I started writing my own but then came across this I made a full copy except at the end I got errors error: Failed to start domain 'Win10Base-3' error: operation failed: unable to find any master var store for loader: /usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd to fix it , all I did was to "edit" the vm and changed anything and updated, then it runs fine I tried it again to compare the before and after of the XML and here are the differences non-working version <nvram>/var/lib/libvirt/qemu/nvram/Win10Base-3-3_VARS.fd</nvram> working version <nvram>/etc/libvirt/qemu/nvram/eaf488d4-a3b9-4fdd-bd9c-fedd3ac4dae6_VARS-pure-efi.fd</nvram> I have not rebooted unraid to make sure everything got saved to the right places in the config, will let you know if there are any issues after a reboot. great script, except for that one glitch, works awesome. Thank you

Thank you

Hi, Thank you for the container, nice to a one that has PHP 8. I am writing something in PHP and wanted to fork some child processes for certain http requests using pcntl_fork, however, it does not look like it is enabled in your container. Would you happen to have a version where pcntl is enabled or could you enable it and include the module? Thank you Piyper

Thank you all for the replies, I went through a few videos by Spaceinvader One, very helpful, I should have checked his channel first anyway , not sure why I didn't earlier. I have been using unraid for a long time, but have not had to do something like this for a while (I think I was using "unMenu") and I don't think this type of conversion was not available, things have changed a bit Interesting enough, I can't remember the last time I had to go into "maintainace mode" so didn't remember anything you could do in there. I guess it goes to show you how stable unRaid is. Thank you all for your help. Piyper

I guess I was thinking that you could not format a drive while it was part of the array and you had to take it out of the array and once you did that, the parity would have to be rebuilt. I didn't know you could reformat a disk while it is still part of the array, I figured that even an empty drive would "compare" differently with two different formats, therefore as soon as you format the disk and put that disk back into the array the parity (on both parity drives) would not match the data on the drives anymore. I guess I am making am assumption about how parity is stored and if just one bit is different (say from a different format) that that part of the parity would not be correct anymore and unraid would just force a parity rebuild. I apologize if I am missing something and and I do thank you for your patience and help

I have another question then. If a parity rebuild would rebuild the drive with the original format, then I assume the once empty a drive, reformat it and bring the array back up with the new format, the both parity drives will be invalid and will force a parity check/rebuild of the parity drives. this would mean I would have no parity protection for a while. Does this sound correct? Piyper

I didn't know that, I figured the "data" was paritied (parityd, hmm, parity'd) and not the entire drive layout Thank you for the suggestion, unfortunately, my two parity drives are more than twice the size of the biggest data drive (planning for future upgrades), that would force me to upgrade at least one of the data drives now and Santa didn't bring me any new drives I have an other unraid server I use for backing up my important stuff from my main server, there is enough space on that to move data around, it will just be slow over the network. Thank you again for the help

Hey there follow unraiders, I have I have two parity drives and a bunch of data drives, however, three data drives are still reiserfs and wanted to make sure they are ready for 2025, I am a little tight on space ATM and don't really have the space to move the data off them. I think what I have in mind should work, but thought I would ask here. I was thinking I should be able to just stop the array and reformat one of the data drives and then just start the array again, the parity should rebuild that one drive. once done rinse and repeat for the other two. Any issues with that strategy? Thank you

Hi there, really nice addition. I have a feature quest if you have some time , I looked to see if anyone has asked for this already, sorry if this is repeat. I have some containers that I do not autostart, mostly development environments for different projects. I have grouped these environments into different folders and start/stop them manually when I need them. When I manually start them, It would be nice if they started in a certain order and we could put a delay between them. For instance; I would like my database container to fire up first and wait about 15/20 seconds before the application server starts. I have more complicated scenarios, but you get the picture. it would be really cool it I could add a script pre/post for each container were I could interrogate the environment to see if it is running or not before the next one was started, but that would just be a cool addition Right now I use my own scripts to start things in the right order, but would be nice if it was built in to your start option. Thank you again for the great utility, keep up the great work

I am in favour of this as well, I would not even worry about what is on the rest of the parity drive, leave it in whatever state it/they are, you don't even really have to clear it. Simply stop at the size of the largest data drive, then when/if a new bigger drive gets added to the array and increases the top level, simply force a parity check on the remaining portion or do a full parity rebuild if the other is not possible. (can't see why it would not be possible) in my case, my largest data drive is 6TB (soon to be 8TB), but my two parity drives are 14TB (as I am sure others do, I buy when I get a good deal), so the parity check takes much longer than it would if it stopped at the max data drive capacity. As I hope, most people do a parity check on a schedule (let's say monthly), and in my case, the check takes over twice as long as it would if it would stop at the largest data drive. I would rather do a incremental rebuild for the added top capacity every once in a while when adding a new drive than to have my checks run for days (IMO) needlessly every month. A switch might be nice to support those people that add drives frequently, however, if we can get incremental parity rebuild working, even that would not be that big of a deal (IMO). Thank you

I tried that and it did not work, however I did get it to work. I tried reverting back to a prior version, then I removed it and all evidence of the container to force a new install/config, that still did not work. I then removed it completely again, then upgraded my unraid from 6.9.0-beta35 to 6.11.2, then reinstalling the container again and like magic, it worked with no issues with the exact same configuration I had before (not a restore, I manually configured the new instance the same as the old) All seem to be working again and the only thing I did to make it work was to upgrade the unraid OS. After looking at the contents of the many tars I made, I did notice that the ownership of some of the files were "root" and not "nobody" and the "nobody" might not have had permission to some files. I know I messed around with PUID/PGID a bit on some of those and that might have messed up the permissions, however, even very old backups of the image shows that "nobody" may not have had the correct permissions. Maybe that is why some people suggest running it as root to fix the issue (which did not work for me) Not sure if that means anything, but I thought I would mention it. Piyper