Just like the title says.  Oddest thing.  Here are the steps I take.  Go to User Shares, click on the share I want to delete.  Share status:Share is Empty.  I click the check box next to delete, and hit delete.  I get the next screen that says "Share ******* has been deleted".  User shares now show share is gone.  All my computers that are connected no longer show share.  After I reboot unraid, the share comes back and all computers now see it again.  Here are the last three lines of the log right after I deleted the share, I do see an error but not sure what that means-Yes the share I am trying to delete is called Virtual. Thanks!!

 

Sep 29 06:51:21 UNRAID emhttp: shcmd (20625): set -o pipefail ; rmdir '/mnt/user/Virtual' |& logger
Sep 29 06:51:21 UNRAID emhttp: shcmd (20626): rm '/boot/config/shares/Virtual.cfg' &> /dev/null
Sep 29 06:51:21 UNRAID emhttp: err: shcmd: shcmd (20626): exit status: 1

No, since I deleted it, it is not showing up in any of those.  I just checked those settings and nothing there

Does sound like a bug of some kind. @bonienl might be interested.

 

User shares are odd beasts. They are automatically created based on root level folders on your physical disks. So if, from the command line or via an SMB disk share, you created a root directory called FRED, you'd notice suddenly you have a user share called FRED. If you remove the FRED directory, the user share will disappear.

 

Plot thickens a bit if, through the user shares WebGUI, you customise the user share. This will create a config file. With that config file present, I believe unRaid will continue to report the user share, even if the root level folders are gone.

 

I would check your disks for the root level folder on your disks, and if you find, see if you can manually delete them. Could be a file or directory is still present inside. I expect that is the cause of the user share popping up after the reboot.

I will give that a shot this weekend and report back.  Thanks for the info!!

@SSD (who I note has changed his name but not avatar) made the point I was going to make.

 

I'll add that I believe that root level folders on the cache drive may also cause a share to reappear - you may want to check that, too.

48 minutes ago, FreeMan said:

@SSD (who I note has changed his name but not avatar) made the point I was going to make.

 

I'll add that I believe that root level folders on the cache drive may also cause a share to reappear - you may want to check that, too.

Yes cache is part of user shares

So here is what I did.  I deleted the share again.  Right after, I checked the Cache drive, no folder called "Virtual" anywhere (The share I am trying to delete).  I went into the config folder on the flash drive, and there is no "Virtual.cfg" file anywhere.  I checked the root of every drive, no Virtual folder on any of those.  I just did a reboot, and Virtual is back.  Totally baffled

This is just a shot in the dark, but I recently had a similar issue because I had a deleted share that still had a path mapped in a docker. The docker kept recreating the folder/share.

Bug

 

If ISO Library location (tested on that.  Didn't test the storage for domains) has spaces contained within it, then the first "word" is automatically created.

 

 

Here is an update.  I have turned off all my dockers, and actually deleted them all.  Then turned off the docker all together.  I made sure there were no spaces in the share I am trying to delete.  I deleted it, rebooted.  Low and behold....It came back again! 

Vm's turned on? Read my post above yours

Hahahahaha - SQUID, you nailed it.  So, doing some research in terminal, I found out that I have Folders in root called - Virtual, Machine, Machies, and ISOs.  Only Virtual was showing up in Shares, but the other 3 were coming back in root after a reboot.  So I had a total of 4 folders, one as a share that kept coming back after a reboot.  Squid, I went to my VM Settings, and low and behold, I have attached a picture of what I saw.  I renamed them with underscores, and they never came back after a reboot.  Thank you for the help!

 

On 10/1/2017 at 5:04 PM, wgstarks said:

This is just a shot in the dark, but I recently had a similar issue because I had a deleted share that still had a path mapped in a docker. The docker kept recreating the folder/share.

Thank you!! I'm aware this is a 7-year-old thread but, I just wanted to report that this was my exact issue, I had an unused path in a docker trying to access my deleted share and it would just `mkdir` it when not existing, bringing back a share every damn reboot.

 

To help find the issue (replace `share` by your share name):

 

root@Tower:~# grep -R "/share" /boot/config

 

You might have to exclude some results by adding an additional `| grep -v something` at the end, for example if you use the dynamix file integrity plugin you might get some false positives here. 

Edited March 11, 20242 yr by dnLL

13 minutes ago, dnLL said:

To help find the issue

You can have .cfg files in config/shares folder which contain the settings for shares that no longer exist. These will not create any shares, they just have settings that would be applied if the corresponding share actually did exist. And deleting these won't have any effect on containers that specify paths which would create a share. They would still get created with default settings.

 

If you did want to automate the search in some way (instead of manually inspecting the paths specified in each of your containers on the Dockers page), you would need to search the contents of each of your docker templates in config/plugins/dockerMan/templates-user.

You can have .cfg files in config/shares folder which contain the settings for shares that no longer exist. These will not create any shares, they just have settings that would be applied if the corresponding share actually did exist. And deleting these won't have any effect on containers that specify paths which would create a share. They would still get created with default settings.
 
If you did want to automate the search in some way (instead of manually inspecting the paths specified in each of your containers on the Dockers page), you would need to search the contents of each of your docker templates in config/plugins/dockerMan/templates-user.

Thanks for pointing this out. Obviously when grepping the entire config, I'm not saying "delete every mention of X" but more "hey this might send you in the right direction". Might not necessarily be the dockers, could be a forgotten user script or whatever plugin, hence the wider grep.

Sent from my Pixel 7 Pro using Tapatalk