This issue appears to have surfaced after creating a private user share to exist only on my cache drive and would hold ISO images to support my VM.  I named this share "ISO Library Share".

 

But then mysteriously, a public share named "ISO" would be created on one of the data drives, and every time I delete it, either from accessing the disk share directly and deleting using the remote OS (e.g. OS X Finder in my case) or through the Shares tab of unRAID's control panel, this mysterious "ISO" share would recreate itself somewhere else later on (I never timed when this mystery share would reappear but it seems like it's at least the next day).

 

Annoying and I can't figure out why.

 

Does it have something to do with the unRAIDs cache "mover" system that moves data from cache drives to data drives?  If so, I believe I've checked off everything to indicate that the "ISO Library Share" is not to be copied/moved to data drives.  Even then, the mystery share is not the same name (though it is a subset of it).  Also, this mystery share is always empty; the "ISO Library Share" has 45GB worth of disk images contained within it.

 

 

Is anyone else experiencing this phenomenon?  Is this a bug?

 

FYI, I currently have the one VM deleted as I was just testing the functionality of this feature.  Eventually, I will have one or two VM's established but haven't yet decided which OS's they will be.

Edited April 2, 20179 yr by Auggie

Settings => VM Manager 

 

Turn on advanced view, then edit the Default ISO path.

42 minutes ago, CHBMB said:

Settings => VM Manager 

 

Turn on advanced view, then edit the Default ISO path.

 

What exactly am I looking for here?

 

I've set this path long ago and it looks good to me:  Default ISO Storage Path = /mnt/user/ISO Library Share

 

This path does and has always existed on the cache drive only, and as I said earlier, contains 45GB of images.

 

How does this explain why unRAID continuously creates yet a different public user share on one of the data drives and names it "ISO" and is always empty?

You just found a Bug

Have you deleted the share from the webui?  Shares => User Shares and deleted any folders that it has created?  If there is an iso folder left on any drive then it will be recreated as a share later.

4 hours ago, CHBMB said:

Have you deleted the share from the webui?  Shares => User Shares and deleted any folders that it has created?  If there is an iso folder left on any drive then it will be recreated as a share later.

 

Yep.  Deleted it through the web GUI, but it reappears again some time later.

 

I understand if there is any directory named "ISO" appearing at the root level of any drive a share will be created.  After deleting the "ISO" directory through the web GUI, I manually checked every data drive to confirm that no "ISO" directory or file exists.  But like clockwork, a new "ISO" directory eventually gets created; usually on the data drive with the most free space (but not always).

5 hours ago, me.so.bad said:

You just found a Bug

 

Yea, sure looks like that to me.  But I wanted to solicit opinions in case I missed a setting in unRAID that could be causing this anomaly.

It's definitely possible to remove it, I did so ages ago.   Only other thing I can think of is if it's somehow tied into the Libvirt volume.  Maybe deleting that after setting your own preferences.

 

Not sure if that has any implications for your VMs though.  Wouldn't have thought so if the XMLs are backed up....

2 minutes ago, CHBMB said:

It's definitely possible to remove it, I did so ages ago.   Only other thing I can think of is if it's somehow tied into the Libvirt volume.  Maybe deleting that after setting your own preferences.

 

Not sure if that has any implications for your VMs though.  Wouldn't have thought so if the XMLs are backed up....

 

I no longer have any VMs; they've all been deleted as this was my first foray into exploring them (hadn't known that at some version of unRAID 6, VM was thrown in).  I initially installed Win 10 and after trying it out, scrapped it and was about to try some flavor of OS X when I decided to put this little project on hold for awhile; I still kept the ISO Library Share intact on the cache drive containing installation images.

 

But in the meantime, I've been trying to keep this other "ISO" folder from popping up.  Again, I think its a bug with the daily 'mover' routine in which it sees the directory on the cache drive and even though it's marked to only reside on the cache drive, the 'mover' routine still attempts to copy it.  A "sub-bug" within it reveals that it only parses the first "word" of the directory name, hence this is why it creates the directory "ISO" instead of "ISO Library Share" on the data drive(s).

Not sure I agree with that, purely because I think that bug would have manifested itself before now. Especially as many people here use share names with spaces in them I would have thought if your hypothesis was correct it would cause problems there too...

9 minutes ago, CHBMB said:

Not sure I agree with that, purely because I think that bug would have manifested itself before now. Especially as many people here use share names with spaces in them I would have thought if your hypothesis was correct it would cause problems there too...

 

Normally, I would agree.  But I can't think of any other possible reason why a mysterious empty directory named "ISO" always gets created.  Absolutely no reason.  This unRAID system is purely a media server and there are no directories named with just the word "ISO" anywhere.

 

So I believe this esoteric bug only manifests itself in the way my system is currently configured:  A VM environment was established but then deleted with no other changes to settings and a supporting directory of ISO files allowed to remain intact.

 

Is it possible that there is some 'default' hard-coded directory name of "ISO" that would be used as the default name for supporting ISO images?  That's also a possibility.  One way I can test this is to rename my supporting directory to something without "ISO" in the title but still with multiple words, and see what happens.

 

Anyway, I never had this problem before I started testing and creating a VM.

Edited April 2, 20179 yr by Auggie

Have you deleted the libvirt.img? Stop the VM service, delete it and then restart the service.

6 minutes ago, CHBMB said:

Have you deleted the libvirt.img? Stop the VM service, delete it and then restart the service.

 

 

BTW, I'm not physically located where this media server resides (half-way across the country) so I'm not actively trying to track down this bug.  It's only when I remote in to do some file movements when I notice the notorious "ISO" directory has re-appeared and do my duty to delete it.  But it was nigh time for me to query the forums about this issue to see how common-place (or not) this is.

 

I last was on-site and testing out VM last summer, so it's been a long time and I'm not too familiar with all the steps and necessary files, but I couldn't find "libvirt.img" within the ISO directory.

 

I do have a "Domains" share that contains an OS X image to be the installer of my next VM test, but that's the only file that exists on that share.  Also, this share is set to only reside on the cache drive.  So in reality, I have to user shares on my cache drive, "Domains" and "ISO Library Share", and both are set to reside only the cache drive.

 

UPDATE:  Okay, I discovered I have three cache-drive only user shares: "System", which DOES contain the libvirt.img file, and the other two user shares I mentioned previously.

 

VM Manager was active (running) so I just disabled VMs.

 

I'm going to stop there (not delete the libvirt.img file) and see if that in-and-of-itself prevents the "ISO" directory from being created...

 

And if this does stop this folder being created, then I believe it's still a bug because this "ISO" folder was created when I did have an active VM installed when there doesn't appear to be any reason for it to exist.

Edited April 2, 20179 yr by Auggie