Jump to content

All Private User Shares - Problem With This?


_0m0t3ur

Recommended Posts

8 hours ago, DoItMyselfToo said:

 Did you also make the default shares (appdata, domains, isos, system) private?

In my case appdata is private and hidden, domains isn't exported at all, iso's is private, and system isn't exported at all.

There is no requirement to make any of those available over the network.

Best security is least possible access to make things work.

Link to comment
On 6/19/2018 at 6:32 AM, jonathanm said:

In my case appdata is private and hidden, domains isn't exported at all, iso's is private, and system isn't exported at all.

There is no requirement to make any of those available over the network.

Best security is least possible access to make things work.

I have read of a number of connection issues and file permissions issues showing up from various network access configurations.  They're mostly much older posts.  I just wasn't sure, so I figured it's better to ask.  Thank you.

 

One thing I did discover related to my current guest SMB network sharepoint connection in OSX, if I create a user share with as "Recipes" and then decide I want to change the name to "recipes", and change the name, then my sharepoint connection is broken.  To fix this I had to delete the user share and recreate as "recipe" then it works fine.  Now that I think about it, maybe rebooting the server, instead of the delete/recreate, would have fixed it.  I don't know.  But it made me question more carefully a few things before I get all my data migrated.

 

Link to comment

In Linux Recipe and recipe would be two completely different shares, so different paths to the share. This is probably what caused your issue connecting. I have seen that some people recommend always using lower case to avoid problems. Regardless, if you change the name of a share you also change the path to it.

 

Not sure how you have your share point set up in macOS but @gridrunner did a video on how to setup a root share that should provide access to all your shares.

Link to comment
On 6/19/2018 at 8:41 AM, wgstarks said:

In Linux Recipe and recipe would be two completely different shares, so different paths to the share. This is probably what caused your issue connecting. I have seen that some people recommend always using lower case to avoid problems. Regardless, if you change the name of a share you also change the path to it.p

 

Not sure how you have your share point set up in macOS but @gridrunner did a video on how to setup a root share that should provide access to all your shares.

 

Yeah, I glanced at @gridrunner 's video.  I may end up looking at it more closely.  By default, OSX shows my server on the local network.  What I didn't point out is that when I changed the share back to the original "Recipe" then I could connect via OS X.  It was because I decided to change my existing capitalized share naming to all lower case to make life easier should I need to utilize Terminal.  It was like the change from "Recipe" to "recipe" wasn't recognized, even though I made the change in the User Share tab of unRAID and clicked apply.

Link to comment
1 hour ago, wgstarks said:

So Finder was still showing the old share after you changed it? Haven’t run into that before. Probably rebooting the unRAID server would have fixed it. Or maybe refreshing (force quit) Finder.

After force quitting Finder and reconnecting, the problem persisted.  You're probably right about rebooting the server, though i didn't try that.  In the end, I deleted the shares and recreated.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...