Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array

[trurl]

I am using the docker dolphin

It may be that you aren't copying things where you think. Are you sure you can even see the UD drive in dolphin? Dockers will not be able to see anything that was not already mounted when the docker service started, and by docker service I don't mean the dolphin container but the docker service that all dockers use.

 

Show the volume mappings for dolphin and where in dolphin you are copying the files to.

[alloveru]

Strange... seems to be working now. Must have been because I started/mounted the drive after the Docker service itself was started.

 

Thanks for your help. Greatly appreciated!

[danioj]

I just wanted to report back that after several weeks now running the plugin by dlandon I have not had a single issue. For what I use the Plugin for (mounting an SSD drive outside the array and running Docker and VM's from it) it is working perfectly!

 

Just taking the time to give Feedback! Thanks again for picking up the Slack on this Plugin! I appreciate it!

 

As a side note it "looks" like gfjardim is not making a return any time soon! He is continuing to log on (according to the forum "Last Seen" logs) so like others, I am sure, I hope he is well and just getting on with important real life stuff!

[ljm42]

Hi dlandon,

 

Thank you very much for all of your work on this plugin, it is a very important part of the unRAID ecosystem and I'm sure a lot of people appreciate your efforts!

 

I just updated my PhotoImport script and I have a couple laundry list of comments/questions/requests for you when you get a chance 

 

 

1. I have one of these multi-card USB card readers:

  http://smile.amazon.com/SIIG-SuperSpeed-Multi-Slot-Reader-JU-MR0712-S1/dp/B004ZMF824

which looks like this in Unassigned Devices:

It shows a greyed out "format" button when a card has not been inserted, I was wondering if that could be changed to something like "Insert", since "format" doesn't really make sense in this case?

 

2.  I'm confused about how this plugin handles slack packages.  It appears that everything is dowloaded from various places on the net, yet two (older/unsed?) packages are also in the github repo:

  https://github.com/dlandon/unassigned.devices/tree/master/packages

Would it make sense to put them all in github or remove them all from github?

 

Below is what I have in /boot/config/plugins/unassigned.devices/packages, would you agree that I can remove the ones I marked with stars?

 

* exfat-utils-1.1.1-x86_64-1_SBo.txz
- exfat-utils-1.2.1-x86_64-1_slack.txz
* fuse-exfat-1.1.0-x86_64-1_SBo.txz
- fuse-exfat-1.2.1-x86_64-1_slack.txz
- hfsprogs-332.25-x86_64-2sl.txz
- libbsd-0.6.0-x86_64-1sl.txz
- libnl-1.1.4-x86_64-1.txz
* nmap-6.40-x86_64-1.txz
- ntfs-3g-2015.3.14-x86_64-1.txz
- parted-3.1-x86_64-1.txz

 

 

3. In the first sample script, I'd recommend putting quotes around $OWNER so the script won't throw errors if you try to run it from the command line:

  if [ "$OWNER" -eq "udev" ]

Just one of those little things that makes debugging easier

 

Under what circumstances would the $OWNER not be set to "udev"?

 

4. In the first sample script, wouldn't it be better for sync to be part of the REMOVE action?  Actually, is there a reason the plugin shouldn't automatically take care of that when unmounting a drive?

 

5.

There is a log file available that will log any errors from running your script file.  It is located at /tmp/ and is by the serial number or label of your drive/SMB Mount point.

 

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?

 

 

Thanks again!

[dlandon]

Hi dlandon,

 

Thank you very much for all of your work on this plugin, it is a very important part of the unRAID ecosystem and I'm sure a lot of people appreciate your efforts!

 

I just updated my PhotoImport script and I have a couple laundry list of comments/questions/requests for you when you get a chance 

 

 

1. I have one of these multi-card USB card readers:

  http://smile.amazon.com/SIIG-SuperSpeed-Multi-Slot-Reader-JU-MR0712-S1/dp/B004ZMF824

which looks like this in Unassigned Devices:

It shows a greyed out "format" button when a card has not been inserted, I was wondering if that could be changed to something like "Insert", since "format" doesn't really make sense in this case?

 

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.

 

2.  I'm confused about how this plugin handles slack packages.  It appears that everything is downloaded from various places on the net, yet two (older/unsed?) packages are also in the github repo:

  https://github.com/dlandon/unassigned.devices/tree/master/packages

Would it make sense to put them all in github or remove them all from github?

 

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.

 

Below is what I have in /boot/config/plugins/unassigned.devices/packages, would you agree that I can remove the ones I marked with stars?

 

* exfat-utils-1.1.1-x86_64-1_SBo.txz
- exfat-utils-1.2.1-x86_64-1_slack.txz
* fuse-exfat-1.1.0-x86_64-1_SBo.txz
- fuse-exfat-1.2.1-x86_64-1_slack.txz
- hfsprogs-332.25-x86_64-2sl.txz
- libbsd-0.6.0-x86_64-1sl.txz
- libnl-1.1.4-x86_64-1.txz
* nmap-6.40-x86_64-1.txz
- ntfs-3g-2015.3.14-x86_64-1.txz
- parted-3.1-x86_64-1.txz

 

They are ignored by UD so they are harmless, but you can remove them.

 

3. In the first sample script, I'd recommend putting quotes around $OWNER so the script won't throw errors if you try to run it from the command line:

  if [ "$OWNER" -eq "udev" ]

Just one of those little things that makes debugging easier

 

Under what circumstances would the $OWNER not be set to "udev"?

 

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"

 

4. In the first sample script, wouldn't it be better for sync to be part of the REMOVE action?  Actually, is there a reason the plugin shouldn't automatically take care of that when unmounting a drive?

 

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.

 

5.

There is a log file available that will log any errors from running your script file.  It is located at /tmp/ and is by the serial number or label of your drive/SMB Mount point.

 

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.

 

Thanks again!

[gfjardim]

Add SMB Mount

 

I added back the hosts lookup.  It seems that it was not using nmap after all.  The hosts lookup uses 'nmblookup'.  I still have issues with it on my network.  I only get the host of the server and nothing else.  Most have reported it working, so I put it back in.  I suspect that I have a setting on my smart switch that is preventing it from working.

 

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.

 

 

Squid,

 

It is now out of beta.  Do your magic.

 

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. 

[dlandon]

Add SMB Mount

 

I added back the hosts lookup.  It seems that it was not using nmap after all.  The hosts lookup uses 'nmblookup'.  I still have issues with it on my network.  I only get the host of the server and nothing else.  Most have reported it working, so I put it back in.  I suspect that I have a setting on my smart switch that is preventing it from working.

 

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.

 

 

Squid,

 

It is now out of beta.  Do your magic.

 

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.

[CHBMB]

gfjardim, I'm also glad you're ok, but I don't think it's fair to level any criticism at Dan here. 

 

Without any reply from yourself, he did the very best he could, which as far as I'm concerned, has been a wonderful job with the information he had available to him, and he did go to significant lengths to liase with yourself first and has successfully fixed a few issues with the plugin that had been problematic for a little while.

 

I think a thank you would have been appreciated.

 

I'm sure with some liason that any issues to resolve moving forward can be ironed out and welcome back.. 

[gfjardim]

As I said before, I did not criticize dlandon, just his decision. I know it's difficult to pick some code and start to fix it, and I do appreciate that effort. It's not about control the code, it's about to make things evolve forward, not sideways. I'm being selfish, I know, I wanted to pick the code debugged and start to improve it.

 

Well, it's done and now I have to try to keep up. Now that you all know my idea about my last version, do you think it's valid to revert it back, iron the bugs out and add image mount?

 

I would appreciate if you guys to join the effort.

[RobJ]

So great to see you back, gfjardim!  I fully understand setbacks, just out of the hospital myself, life happens!

 

I think credit is due everywhere here, definitely not blame.  This plugin was the result of some great work, and had become so important to many users, that when life intervened with the author and maintenance was required, another user stepped in.  His work was so successful, a stream of additional requests began, and time passed.  Yes, with the passing of time, the distance between the forks necessarily widened, but it's not insurmountable.  And I think we all agree we don't want another situation like the past.

 

This brings up something I've been thinking about for awhile - the real need (a critical need in my opinion) for a stated succession plan or backup author for ALL plugins and Docker containers.  The backup person does not have to be as gifted, just capable and willing to carry on in a limited way at least, if something should happen to the original author.  Right now, the Linuxserver.io group have an important advantage over others, a built-in succession plan.  I find it worrying to consider what would happen if something happened to PhAzE or binhex or a few other authors, with the number of plugins and containers and so many users depending on them.  I hope they will consider finding someone they can assign, 'just in case'.  I hope that Squid will consider the possibility of adding another field for this, so that when users evaluate equivalent options, the one with a backup plan has a significant advantage.

 

I understand not every plugin or container needs a backup person or plan.  In some cases, you should be able to remove one container, load a similar one, and carry on with little change, and no loss.  But that's certainly not true in many cases, especially important plugins like this one.

[dlandon]

As I said before, I did not criticize dlandon, just his decision. I know it's difficult to pick some code and start to fix it, and I do appreciate that effort. It's not about control the code, it's about to make things evolve forward, not sideways. I'm being selfish, I know, I wanted to pick the code debugged and start to improve it.

 

Well, it's done and now I have to try to keep up. Now that you all know my idea about my last version, do you think it's valid to revert it back, iron the bugs out and add image mount?

 

I would appreciate if you guys to join the effort.

 

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.

[ljm42]

Hi dlandon,

 

Thank you very much for all of your work on this plugin, it is a very important part of the unRAID ecosystem and I'm sure a lot of people appreciate your efforts!

 

I just updated my PhotoImport script and I have a couple laundry list of comments/questions/requests for you when you get a chance 

 

<snip>

 

I really appreciate your responses dlandon!  Looks like I just need to move my sync command from REMOVE to ADD and I'll be good to go.

 

And welcome back gfjardim!

[danioj]

Add SMB Mount

 

I added back the hosts lookup.  It seems that it was not using nmap after all.  The hosts lookup uses 'nmblookup'.  I still have issues with it on my network.  I only get the host of the server and nothing else.  Most have reported it working, so I put it back in.  I suspect that I have a setting on my smart switch that is preventing it from working.

 

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.

 

 

Squid,

 

It is now out of beta.  Do your magic.

 

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. 

 

Welcome Back Guilherme! It is VERY nice and comforting to read that you are OK and that the challenges / setbacks in your life have been overcome to see you actively rejoin the community. I fully understand setbacks in life. As a Project Manager of very large Complex Projects I am unfortunately made acutely aware of how many people experience setbacks and their impacts on their ability to maintain their contribution in life.

 

Lots of People. Everyday.

 

I make a point of always making every effort to re-integrate and support any individual I can back into a substantive role to facilitate the come back process. You (like many others) are a victim of your success and skill and as such WE MISS YOU when you are not here. In this instance, many community members (myself included AND I think Dan too) came to rely on this plugin as a core component of their IMPORTANT setup. That Credit can only go to you and for that I'd like to speak on behalf of others (which I excuse myself if I speak out of turn here) I thank you. Your plugin made unRAID better IMHO.

 

All that being said, I completely disagree with a number of your comments. I don't want to make a point of all of them BUT one resonates with me and I feel the need to address it.

 

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. 

 

Dan's decision to support us and Fork your code was NOT arbitrary. An arbitrary decision implies a decision that was made with undue use of assumed or given control, random choice, made on a whim or done so without reason. I don't think any of those conditions apply here. If you take the time to go back and read the history leading to the fork I don't believe you will come to this conclusion too.

 

The community - me included - reported an issue which was causing system instability (and while this might be argued - the fact is enough people considered it to be so) and unfortunately while you were managing your issues you were unavailable to help.

 

IMHO - it almost got to a point where a fork was necessary or stop using the plugin. Dan initially communicated he had managed to fix the issue - which thankfully (and I still owe him a beer here) he shared. When "We" asked him IF he would be willing to take over if you didn't return, Dan initially resisted. I believe he was quite rightly apprehensive in his response to this request as I feel he is already one of the more prominent contributors to this wonderful community and to take on more responsibility which, lets be frank, eats into your personal time - takes thought.

 

More time passed and still you didn't return. More and more people had varying issues of varying importance and traffic increased. Ill say it again - the very fact that your development caused so much traffic is only a testament to you and your excellent contribution BUT a downside of that is that people rely on such contributions and a resolution to issues / defects is needed.

 

I won't repeat what RobJ talked about re identifying individuals as backups to continue development for Plugins (Or at least the ones that become so popular and that users depend one for critical functionality) on the unfortunate chance of something happening to one of out community - but I absolutely agree with it.

 

I have noted what I do for a living and ONE of the biggest things I deal with EVERY day managing and dealing with hundreds of people is that while we can feel for individual, give our sympathies and support for whatever is happening - life goes on. It is expected to go on. People DEMAND that it goes on. In addition often people (especially those at the top) DEMAND that it does so without missing a step. This is sort of what happened here I feel.

 

I hope you consider retracting some of what you said to Dan re the decision he made with the thanks of anyone I saw posting, selflessly and under (some probably undue) community pressure. The implication that the code amendments made, were done were substandard, didn't move the Plugin forward or that nothing was improved - I believe is false. I don't agree with that personally nor do I believe the facts support it.

 

debugging the code again.  We've been through a lot in the last month.  I'm not interested.

 

I do not blame Dan for responding in the way that he did. I personally wouldn't be interested in doing what you asked either. TBH I think the comments you made about the approach taken to managing your absence didn't help at all.

 

I am not sure about what I think is the best way forward here. Dan has done a fantastic job and his attitude is fantastic. Selfishness doesn't often work in a community in my experience. I don't know either of your plans here BUT FWIW I would sacrifice forecasted enhancements on this plugin FOR the drive, support and attitude Dan has demonstrated any day of the week. If you are to take control again and Dan is to step - my only hope is that you can take on board some of the excellent qualities Dan has demonstrated over the past few months.

 

Once again - I am very glad you are ok. The community is better with you in it. Thats a Fact.

[dlandon]

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.

[gfjardim]

Ok, you won. Let's make things right then. I still have all copyrights over the code and your license manifests are illegal, null and voided. Please remove them, submit your changes in a PR to my repository. I'll accept it, GPL it, an then you can fork it over your repo and continue the development. I'll deprecate my version when it's over.

[dlandon]

Ok, you won. Let's make things right then. I still have all copyrights over the code and your license manifests are illegal, null and voided. Please remove them, submit your changes in a PR to my repository. I'll accept it, GPL it, an then you can fork it over your repo and continue the development. I'll deprecate my version when it's over.

 

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.

[gfjardim]

I'm not threatening you, just making sure it's legally licensed to protect our community users in the case a third party make contributions to the code and later demand any rights over it. If I surrender my copyrights it will be in favour of all community.

 

So I'm correcting an error, not making a new one.

 

[dlandon]

I'm not threatening you, just making sure it's legally licensed to protect our community users in the case a third party make contributions to the code and later demand any rights over it. If I surrender my copyrights it will be in favour of all community.

 

So I'm correcting an error, not making a new one.

 

Understood.

[dlandon]

Ok, you won. Let's make things right then. I still have all copyrights over the code and your license manifests are illegal, null and voided. Please remove them, submit your changes in a PR to my repository. I'll accept it, GPL it, an then you can fork it over your repo and continue the development. I'll deprecate my version when it's over.

 

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

[gfjardim]

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

 

You closed it. Fork my repo, remove my files, put yours, commit it an then send the PR.

[dlandon]

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

 

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.

[Squid]

I struggle with github,

You're not the only one lol

[gfjardim]

Just updated my repository with code properly GPL'd.

 

Good luck Dan.

 

[weirdcrap]

I just installed your plugin and it seems to be working fine (I haven't tried to mount anything yet as I am not home) except I seem to be missing the log and script icons in the webgui. I tried removing the plugin and reinstalling from the repo to no avail.

 

Looking in the flash\config\plguins\unassigned.devices\ directory there is no icons folder (which is where the plugin appears to be looking for these icons).

 

Here is a link to my Diagnostics dump: https://dl.dropboxusercontent.com/u/70586667/void-diagnostics-20160210-1707.zip

 

Let me know if there is further information you would like me to provide.

 

[dlandon]

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.