confused about private shares and permissions (macOS Mojave, SMB)


Recommended Posts

hello everyone,

 

i just started playing with unraid and ran into some issues that I could not find any information for.

I have setup an user, let's call him "USER". I have also created a private share where only USER has read/write access and nobody else.

I have copied some files over SMB (only SMB enabled, with macOS interoperability or whatever it's called) after logging in with USER/USERPASS from macOS.

And this is where the confusing issues for me start:

- tried to  delete files over the network ,it told me some of them are in use and it can't

- noticed that files in the /mnt/user/USERSSHARE/ folder have a user:group of USER:users instead of nobody:users as it's mentioned all over the forum

- ran Docker Safe New Perms which made the files in the private share owned by nobody:users as well

- i was able to delete files without anymore issues over the network

- if i copy a new file over, it gets an ownership of USER:users

 

i am not sure how this should work, or if i need to do something, flip some options somewhere, but it feels completely inconsistent. i would have to run fix perms after each copy to make sure i can do stuff with the files ...

 

any hint is appreciated, cheers

alex

Edited by undreaded
Link to comment
  • 3 weeks later...

OK, I am going to ask a question here that might seem stupid.  Is the the name of the 'USER' actually in all small letters without and Capital letters in it?  Here is the allowed naming parameters:

Quote

 

Usernames may be up to 32 characters long and must start with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes. They can end with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]?

 

 

 

With that out of the way, are you using a MAC or a PC?   

 

Have you tried to see what happens if you turn off 'macOS interoperability'?

 

You may why all of these types of questions?  It is because this is the first time that I have ever heard of the condition where a transfer via SMB from another computer has had the owner:group names changed from anything other than 'nobody:users'.  (Usually--  'root:users') Most commonly this happens when a Docker App or VM has some setting incorrect.

 

Setup a new share (strictly for testing) whose security is set to 'Public' and see if the same thing happens to the owner:group.  Try it with both logged in and not logged in (if possible).  

Edited by Frank1940
Link to comment
2 hours ago, Frank1940 said:

You may why all of these types of questions?  It is because this is the first time that I have ever heard of the condition where a transfer via SMB from another computer has had the owner:group names changed from anything other than 'nobody:users'.  (Usually--  'root:users') Most commonly this happens when a Docker App or VM has some setting incorrect.

Anytime I create a file or transfer from Windows to unRaid, it always has my user name as the owner.  For background, I do not use a microsoft account, but rather a local account on the Windows machine

806941066 drwxrwxrwx 1 nobody users          76 Aug 21 22:28 ./
538477922 drwxrwxrwx 1 nobody users         114 Aug 16 19:48 ../
806941101 -rw-rw-rw- 1 andrew users 25505687802 Aug 21 22:08 SomeRandomFile.mkv
806941088 -rw-rw-rw- 1 andrew users           0 Aug 21 22:28 New\ Text\ Document.txt

And, so long as it's still a member of the users group, there isn't a problem with any other user modifying / deleting files.

Link to comment
8 hours ago, Frank1940 said:

OK, I am going to ask a question here that might seem stupid.  Is the the name of the 'USER' actually in all small letters without and Capital letters in it?  Here is the allowed naming parameters:

With that out of the way, are you using a MAC or a PC?   

 

Have you tried to see what happens if you turn off 'macOS interoperability'?

 

You may why all of these types of questions?  It is because this is the first time that I have ever heard of the condition where a transfer via SMB from another computer has had the owner:group names changed from anything other than 'nobody:users'.  (Usually--  'root:users') Most commonly this happens when a Docker App or VM has some setting incorrect.

 

Setup a new share (strictly for testing) whose security is set to 'Public' and see if the same thing happens to the owner:group.  Try it with both logged in and not logged in (if possible).  

hi, thanks for replying

 

USER is a placeholder for whatever user might be, in this particular case my user is "alex" (no quotes, lowercase :P )

using a MAC and time machine on some other shares so interoperability is on, i m not sure what it does, but i assumed it would be good to have it on as i m using a mac

 

i wouldn't have a problem with it being under my user, it is probably preferred, but somehow, it seems i can't delete random files/folders if they are not all under nobody:users 🤦‍♂️

 

will try the public share test and report back, thanks

Link to comment

just created a public share, copied over a file from my mac, it is also under the user i was logged in with in finder/smb

-rw-rw-rw- 1 alex users 904K Aug 13 02:07 a-splash.jpg

i ll copy some folders over and try to delete to see if the same problem with being unable to delete manifests itself

 

/edit:

tried it, copied folders over, tried to delete, got "The operation can’t be completed because the item “this is a folder name” is in use."

chown to nobody:users, was also not able to delete

left it a while, the folder "in use" changed and was able to delete part of the files.

left it some more, and was able to delete some more

left it some more, was able to delete all

 

and now i am more confused than ever... is there some kind of indexing service. or something locking files immediately after write?

i ll redo the whole test above, with some longer periods of time between actions....

Edited by undreaded
tested
Link to comment
2 hours ago, undreaded said:

and now i am more confused than ever... is there some kind of indexing service. or something locking files immediately after write?

Well, Windows does have an indexing function with the 'purpose' of speeding up searching for file content.  (It can be turn-off which is what I have been doing for many, many years now.)  I suppose it is possible that  MAC's have a similar function.  Are you mounting your shares as a drive on your MAC or are using a file manager to access them?  (Either way should work.... should work...  should work...   🙄 )

 

I would like to make a suggestion.  Edit your first post and modify the title of this thread to reflect that you are using a MAC and what version of the OS you are using.  Two or three words at the beginning or end would be enough.  Let's see if we can get some MAC folks' input on what is happening. 

 

PS--  I did find this by doing a Google on   file indexing on MAC  :       https://support.apple.com/en-us/HT201716   So there is some sort of indexing that can happen.  I would think that File Indexing on a mounted share on another computer would not be a particularly  desirable situation.  

Link to comment

thanks @Frank1940 for looking into this.

i have updated the title as instructed.

by default spotlight (file) indexing is disabled for network drives, but i added the folder to the ignore list just to be on the safe side. i also checked it s status

/Volumes/public-test:
	Indexing and searching disabled.

 

i left some time to pass, nothing changed, still erroring, but i did find out something new.

 

if i issue delete repeatedly while ignoring the in use error, i can eventually delete everything, as the folder that shows up in use, keeps changing. how weird is that?!

and this happens with the owner set to alex:users

i have also found out that a "sudo rm -rf" from the mac on the mounted folder deletes fine without ever complaining....

 

Edited by undreaded
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.