dlandon

Well it turns out the icons are there and display correctly when viewing Tower/Main but not under Tower/Main/UnassignedDevices. I tried to view the page in both Firefox and Chrome after clearing the browser cache. That is quite curious. You put Tower/Main/UnassignedDevices in the browser URL. I did that and reproduced what you found. I didn't know that even worked. Let me take a look. Well I am still new to UnRAID 6 and the whole plugin/docker interface and I found that by simply clicking the plugin image under the installed plugins page (at least for some plugins like swap file) I could quickly get to the settings/interface for that plugin. So that is what I did with this plugin thinking that was the quickest way to get to the interface. What you did is quite acceptable and not something I do, so I didn't catch it. I have it fixed in the next release.

Well it turns out the icons are there and display correctly when viewing Tower/Main but not under Tower/Main/UnassignedDevices. I tried to view the page in both Firefox and Chrome after clearing the browser cache. That is quite curious. You put Tower/Main/UnassignedDevices in the browser URL. I did that and reproduced what you found. I didn't know that even worked. Let me take a look.

Those icons are not stored on the flash drive. They are part of the tarball bundle that is expanded into the memory drive. I would suggest clearing your browser cache and possibly trying a different browser. If that doesn't work, start a console session and type "ls /usr/local/emhttp/plugins/unassigned.devices/icons" and you should see: edit_script.png* hourglass.png* remove.png* unassigneddevices.png* view_log.png* These are the icons for the webgui.

You closed it. Fork my repo, remove my files, put yours, commit it an then send the PR. Try now. Let's move this to PMs if you need to communicate any further with me.

I struggle with github, but I think I got it. Confirm that I did the pull request properly.

Understood.

It's not really a matter of winning, it's what is best and least disruptive to the community. You really don't need to play the legal card. I will honor your request and don't need to be threatened to get it done. This does bring up an issue that I think LT should weigh in on. Should all plugins be gpl licensed to start with so development can be forked and move on without going through these issues? I assume that a plugin would be gpl licensed, but it would be best to clarify up front.

Based on pm feedback, it seems to be the consensus that we should stay on the current path with UD. I will continue to support and enhance the plugin. I plan on adding iso mount when I've settled on how to offer the best user experience. Technically it is almost trivial. If gfgardim feels strongly about him implementing the iso mount, I'd recommend he do a code pull from my github, do his work and I'll incorporate his changes. I will of course do extensive testing. Right now the plugin is working well, and is stable. I don't think we should do anything to disrupt what we have accomplished in the last month.

I also see it on the console.

I don't want to rain on your parade, but going back and debugging your latest version would prove to be a major effort that I am not interested in participating in. I have put together a list of the bugs I've fixed and it is extensive and would in my mind take a lot more work than you adapting to what I've done. Adding iso mounts is interesting, but not worth the effort you are talking about. It could be easily added to what I've done. I don't know if anyone else would be interested in debugging the code again. We've been through a lot in the last month. I'm not interested.

Nmap was used to map NFS servers on the current network, so if you didn't include the NFS part of the code, it isn't necessary. As you took the 19.09 version of gfjardim as a basis for further development, I wonder which features of the newer gfjardim versions are no longer available in your newest version? gfjardim's change log: 2015.11.18 - Fix: better logging - Add: force unmount after 5 attempts 2015.09.28b - debug: debug version 2015.09.25 - Fix: minor fixes 2015.09.22b - Add: NFS share mount The NFS share mount was added to this version. I don't know why, but he was in the process of rearranging the code. As I looked through his latest version, I saw a lot of things that were broken. I extracted what I could use from that version. I chose not to use his 2015.11.18 version because I didn't want to troubleshoot half-written code and too much was not working. If anyone that was successful in using his latest version sees any feature I missed, let me know. This was because I was modularizing the code, so with little work we could map NFS shares and mount ISO or other images. It wasn't half-written, just had some bugs to iron out. I'm disappointed you took this step and forked an inferior version of the code. Now, when I resume the development, it will be more difficult to include any improvements you made. See, I don't blame you on moving ahead since I had some setbacks and didn't had the time to work on this. But this arbitrary choice of yours resulted in two codes that can't be reconciled without a lot of work. First I'd like to say I'm glad you are ok. We haven't heard from you in a long time. The NFS shares functionality has been added, but without nmap. None of your versions since 2015.09.19 would even mount a USB for me. I posted many times without any response, I uploaded logs, and I PMd you with no response. When it was apparent that latest version of your UD was not working well for anyone, I PMd you again and got no response. I did not want to fork UD, but it is important functionality for me and quite a few others and we were all struggling with it. I made an arbitrary choice to go with the 2019.09.19 version because it had less issues. I didn't see it as an inferior version. I was not in the position to trouble shoot your latest version that hadn't had much time to shake out problems and had more that just a few bugs to work on. I see that you feel I made a bad choice, and I'm sorry that you feel that way. Without any communications of any kind from you, I made the best choice I could. Nowhere in your change log did you mention that you were working on modularity. It's hard enough taking over some one else's code, let alone trying to figure out what they had in mind with no documentation. When you decide to pick up the development again, just continue on from where you left off and don't use any of my modifications. I've really spent more time fixing things than adding new functionality anyway. Just let me know, and I'll stop my efforts.

It looks like UD can tell the difference. I'll have to see if I can get a card reader and do some testing. EDIT: I think a card in the reader that is not formatted and a card not inserted is seen by UD as the same. The Format button is grayed out on your screen shot because you have destructive mode turned off. Traditionally the packages are gotten from various repositories on the net. The two that are on my github were compiled originally for the UD plugin. I've left them on github for historical reasons so an older plugin version will be successful installing rather than failing when a package is not found. The user could then go to the plugins and update to a newer version. I'd rather have this scenario, than a failed plugin installation leading to a support issue. They are ignored by UD so they are harmless, but you can remove them. The script is not intended to be run from the command line. The environment variables (e.g. $OWNER, $MOUNTPOINT, etc) are defined by UD before the script is called and would not necessarily be correct when the script is executed from the command line. I have provided a script execution button on the gui so you can test your script and see the output in a window. Read the comment in the defualt script: # OWNER : "udev" if executed by UDEV, otherwise "user" It has to be done before the REMOVE action because at that point the device is unmounted. I just did it to be sure the write cache was flushed before unmounting. The problem with it is that it applies to all drives and any drive that is being actively written can keep the sync from completing quickly. I am not sure about including the sync in the UD unmount. That makes three places to look for logs - syslog, $LOGFILE (on the flash) and /tmp/serialnumber.log. I'm wondering if the /tmp file could be moved to the flash drive to make it easier to access? The /tmp/serialnumber.log was something that gfjardim implemented originally. It no longer has much value because running the script from the gui shows the output from the script. I'll probably remove it once I'm convinced there is no value in leaving it. $LOGFILE is at /var/logs/ with all the other system logs, not on the flash.

You are not providing enough information for anyone to help you. What does permissions "seems to be screwy" mean? What version of unraid are you coming from and what are the permissions on the old drives vs the new drives?

As you took the 19.09 version of gfjardim as a basis for further development, I wonder which features of the newer gfjardim versions are no longer available in your newest version? gfjardim's change log: 2015.11.18 - Fix: better logging - Add: force unmount after 5 attempts 2015.09.28b - debug: debug version 2015.09.25 - Fix: minor fixes 2015.09.22b - Add: NFS share mount The NFS share mount was added to this version. I don't know why, but he was in the process of rearranging the code. As I looked through his latest version, I saw a lot of things that were broken. I extracted what I could use from that version. I chose not to use his 2015.11.18 version because I didn't want to troubleshoot half-written code and too much was not working. If anyone that was successful in using his latest version sees any feature I missed, let me know.

Squid, It is now out of beta. Do your magic.

Until this version is taken out of beta status, CA has trouble distinguishing between the two on it's installed section due the identical names (unfortunately not at the top of my list to fix this) Once this is out of beta, gfjardim version will disappear from CA completely and that problem will disappear I'll take it out of beta later today. This situation is quite messy and confusing. I haven't seen any show stoppers come across..

Let me ponder this. My business has picked up because of the nicer weather here in southern Ohio. I won't have as much time now to spend on UD.

Release 2016.02.03 is now available. I have added a script execution window so you can run your script and see the output in a window. When a drive is mounted, click on the Identification (serial number) and you'll see a lightning bolt. Click on the lightning bolt and a window will open and your script will run just as if the drive was plugged in and mounted. The script runs in the foreground regardless of how the run in background switch is set. You can add any standard bash commands as necessary to troubleshoot. This is a valuable tool to test your script and see if if is running properly. There is one down side to this implementation. You won't be able to file check any disk formatted with btrsf. The icon next to the partition information can only be file check or run script. The btrfs file system can only be checked when mounted, so I cannot have that icon be a file check and a script execution at the same time on btrfs. I chose to implement the script execution at the expense of the btrfs file check when mounted.

Yes.

Release 2016.02.02 is now available. I have added script logging with a log viewer. Two new environment variables are passed to the script file. # PROG_NAME : program name of this script # LOGFILE : log file for this script $LOGFILE is a file where your log is saved. You can send whatever you want to the log in your script using an echo command. You can also send output from commands to the log. echo "Started: `date`" >> $LOGFILE rsync ... >> $LOGFILE You can also use the $PROG_NAME for logging or other uses. logger Started -t$PROG_NAME I'll edit the OP to reflect these new features.

I think you are working too hard. Why not just plug in the drive and let the script run and take care of things? I use the following in my scripts and rsync just copies over the changed files and removes any deleted files. The drive I am using is used for a variety of purposes and I simply don't want a load of backups to take place every time it is plugged in. Just a personal preference I guess, but it would be nice to have a manual / automatic switch on the UI. Thanks for the example script, and I like the idea of viewing log output. It would definitely be a great addition, maybe keep the last 5 logs or something for furture reference. Ok. I've got a possible solution for you. Try this: - Turn off the auto mount switch so the script file will not automatically execute when the drive is plugged in. - Create a different script for each of your scenarios. - Plug in your device. - Go to the edit script page and select the script you want to run. - Save the script. - Click on 'Mount' and the drive will mount and execute the script you selected. Next time you plug in the device, select a different script and then 'Mount' the device. You will then control which script runs when the drive is installed.

I think you are working too hard. Why not just plug in the drive and let the script run and take care of things? I use the following in my scripts and rsync just copies over the changed files and removes any deleted files. The drive I am using is used for a variety of purposes and I simply don't want a load of backups to take place every time it is plugged in. Just a personal preference I guess, but it would be nice to have a manual / automatic switch on the UI. Thanks for the example script, and I like the idea of viewing log output. It would definitely be a great addition, maybe keep the last 5 logs or something for furture reference. The rsync example I gave you only copies any changes. There would not be a load of backups each time unless a lot of files have changed. The manual/automatic switch I don't understand. What would that switch do?

I think you are working too hard. Why not just plug in the drive and let the script run and take care of things? I use the following in my scripts and rsync just copies over the changed files and removes any deleted files. LOGFILE=/var/log/DailyBackup PROG_NAME=DailyBackup logger Music share -t$PROG_NAME echo "Music share" >> $LOGFILE rsync -a -v --delete /mnt/user/Music $MOUNTPOINT/ 2>&1 >> $LOGFILE The 'logger' line puts an entry in the log file showing the folder being backed up. The results of the rsync goes to the $LOGFILE. I have an idea that that I want to eventually implement where you would define a log file in UD and have a viewer to see the log from a script. The idea is still in my head and I have not decided on a good implementation yet.

This is fixed in the 2016.02.01 release.

Version 2016.02.01 is available. I fixed the situation where the unraid boot flash drive would show up as an unassigned device when another flash drive is installed with an 'UNRAID' label. The inserted flash drive will show in unassigned devices, but won't mount because it has the 'UNRAID' label. Any device with the label of 'UNRAID' will not mount or unmount. The boot flash device will not show up in the unassigned devices. Because of the changes, please confirm that all your unassigned devices show properly, and the parity, array disks, cache disk(s), and boot flash drive don't show up.