poopsie Posted September 29, 2017 Share Posted September 29, 2017 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 Quote Link to comment
poopsie Posted September 29, 2017 Author Share Posted September 29, 2017 No, since I deleted it, it is not showing up in any of those. I just checked those settings and nothing there Quote Link to comment
SSD Posted September 29, 2017 Share Posted September 29, 2017 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. 1 Quote Link to comment
poopsie Posted September 30, 2017 Author Share Posted September 30, 2017 I will give that a shot this weekend and report back. Thanks for the info!! Quote Link to comment
FreeMan Posted September 30, 2017 Share Posted September 30, 2017 @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. Quote Link to comment
trurl Posted September 30, 2017 Share Posted September 30, 2017 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 Quote Link to comment
poopsie Posted October 1, 2017 Author Share Posted October 1, 2017 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 Quote Link to comment
wgstarks Posted October 1, 2017 Share Posted October 1, 2017 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. 1 Quote Link to comment
Squid Posted October 1, 2017 Share Posted October 1, 2017 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. Quote Link to comment
poopsie Posted October 4, 2017 Author Share Posted October 4, 2017 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! Quote Link to comment
Squid Posted October 4, 2017 Share Posted October 4, 2017 Vm's turned on? Read my post above yours 1 Quote Link to comment
poopsie Posted October 4, 2017 Author Share Posted October 4, 2017 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! Quote Link to comment
dnLL Posted March 11 Share Posted March 11 (edited) 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 by dnLL Quote Link to comment
trurl Posted March 11 Share Posted March 11 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. Quote Link to comment
dnLL Posted March 11 Share Posted March 11 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 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.