Strange changes to share permissions

[DTMHibbert]

Hi All - hope someone can help me with the following issue. 

The permissions on someone of shares seems to be changing automatically - it only seems to affect shares that use the Cache drive, however i created a new "test" share which uses the cache drive and that seems to be working perfectly. 

 

The problem i have is when i copy/ move a file from my windows 10 machine it seems to copy just fine however whenever i try and access that share again i get the message "Windows cannot access \\Zeus\rootshare\media". - if i run the "Docker safe new perms" it does fix the problem and i can gain access to the share again until i copy/ move another file the share and the process repeats. Strangely this process also happens if i right click the share folder in windows and select properties.

 

I've noticed when i run ls -lah  when im able to to write to the share the permissions are "drwxrwxrwx+  1 nobody users    0 Jun 12 10:26 media/" and when i get the error on windows and check ls -lah again the permissions chage to "drwxrwx---+  1 nobody users    0 Jun 12 10:45 media/"

 

I've attached my diagnostics if that helps. 

 

Thanks all

zeus-diagnostics-20200612-1050.zip

[Frank1940]

Give us complete path for the Linux command---   ls -alh

 

Examples:

ls -alh /mnt/user

and

ls -alh /mnt/cache

IF you could provide with the complete output of the ls command where the permissions are wrong.  That would look like this:

root@Rose:~# ls -alh /mnt/user
total 5.5G
drwxrwxrwx 1 nobody users   58 Jun  7 02:30 ./
drwxr-xr-x 9 root   root   180 Jun  1 14:27 ../
drwxrwxrwx 1 nobody users  281 Jun  1 06:01 Backup/
drwxrwxrwx 1 nobody users  273 Nov  6  2017 CommunityApplicationsAppdataBackup/
drwxrwxrwx 1 nobody users   33 Oct 16  2019 Folder_Tree/
drwxrwxrwx 1 nobody users 4.0K Aug 27  2019 Media/
drwxrwxrwx 1 nobody users 4.0K Mar 23 10:07 appdata/
-rw-rw-rw- 1 nobody users  10G Jun 12 09:44 docker.img

IF you would format it as 'Code'   (the  '</>'  icon on the format box of this edit box), it would help us to read it. 

 

4 hours ago, DTMHibbert said:

when i get the error on windows and check ls -lah again the permissions chage to "drwxrwx---+  1 nobody users    0 Jun 12 10:45 media/"

Now to the possible cause of the problem.  The

 drwxrwx--- 

permission says that the item is a directory and the 'Owner' (nobody) and 'Group' (users) have read, write and permission to enter the directory.  'Other' (Of which you are most likely) has no permission to read, write, or enter this directory.  Exactly how is this directory being created?  Is it being done by a plugin or a Docker?

Edited June 12, 2020 by Frank1940
users was user

[DTMHibbert]

ls -alh /mnt/user

root@Zeus:~# ls -alh /mnt/user
total 52K
drwxrwxrwx+  1 nobody users   68 Jun 12 10:51 ./
drwxr-xr-x  13 root   root   260 Jun 11 09:14 ../
drwxrwxrwx   1 nobody users   82 Jun 11 09:49 Downloads/
drwxrwx---+  1 nobody users 4.0K Feb 20 21:45 Nextcloud/
drwxrwxrwx   1 nobody users  402 Jun 10 21:58 appdata/
drwxrwxrwx   1 nobody users   34 Jun  4 08:16 applications/
drwxrwxrwx+  1 nobody users   74 Jun 11 09:49 backups/
drwxrwxrwx   1 nobody users    6 Jun 10 22:25 books/
drwxrwxrwx   1 nobody users   19 Jun 11 09:47 documents/
drwxrwxrwx   1 nobody users   14 May 22 08:16 domains/
drwxrwxrwx   1 nobody users    6 Jun 11 09:21 games/
drwxrwxrwx   1 nobody users   19 Jan 17  2019 icons/
drwxrwxrwx   1 nobody users   80 Jun 11 09:49 isos/
drwxrwx---+  1 nobody users    0 Jun 12 15:27 media/
drwxrwxrwx   1 nobody users   26 May 24 15:21 system/
drwxrwxrwx   1 nobody users    6 Jan 17  2019 tautulli/
drwxrwxrwx+  1 nobody users    6 Jun 11 14:44 test/
drwxrwxrwx+  1 nobody users   90 Jan 17  2019 zeus\ backups/

ls -alh /mnt/cache

root@Zeus:~# ls -alh /mnt/cache
total 16K
drwxrwxrwx+  1 nobody users  68 Jun 12 10:51 ./
drwxr-xr-x  13 root   root  260 Jun 11 09:14 ../
drwxrwxrwx   1 nobody users  82 Jun 11 09:49 Downloads/
drwxrwxrwx   1 nobody users 402 Jun 10 21:58 appdata/
drwxrwxrwx   1 nobody users  14 May 22 08:16 domains/
drwxrwx---+  1 nobody users   0 Jun 12 15:27 media/
drwxrwxrwx   1 nobody users  26 May 24 15:21 system/

the permissions are wrong in a shares that use cache - one of which is media

root@Zeus:~# ls -alh /mnt/user/media
total 40K
drwxrwx---+ 1 nobody users   0 Jun 12 15:27 ./
drwxrwxrwx+ 1 nobody users  68 Jun 12 10:51 ../
drwxrwxrwx  1 nobody users  48 Jun  4 12:40 4K\ Movies/
drwxrwxrwx  1 nobody users 20K Jun  1 09:18 Movies/
drwxrwxrwx  1 nobody users  10 Feb  1  2019 Music/
drwxrwxrwx  1 nobody users 136 Apr  5 15:04 Photographs/
drwxrwxrwx  1 nobody users  99 May 23 03:03 TV\ Shows/
drwxrwxrwx  1 nobody users  10 Apr  5 16:34 Test\ Photos/

All shares are setup in the usual way using share tab, directories within the shares are unusually setup by using my windows machine. 

[Frank1940]

Do any Dockers or plugins work (backup, add files to the share, etc.) on the shares with the following permissions?

drwxrwx---+

I seem to recall  the  --->   +    <--- indicates some kind of special permission (or added permissions) to the resource.   I have seen it before and I seem to recall the addition had nothing to do with Windows...

[Frank1940]

Found something here: 

 

    https://wiki.archlinux.org/index.php/File_permissions_and_attributes

 

 

That link point here:

      https://wiki.archlinux.org/index.php/Access_Control_Lists

[DTMHibbert]

All dockers/ plugins seem to work just fine, at least not spotted any misbehaving just yet. 

 

I've just been doing somemore checking on this and my media share no longer has the "+" in the permissions

root@Zeus:~# ls -alh /mnt/user
total 56K
drwxrwxrwx   1 nobody users  132 Jun 12 15:27 media/

just tried to copy a file to the share and the permissions changed immediatley to 

root@Zeus:~# ls -alh /mnt/user
total 52K
drwxrwx---+  1 nobody users  108 Jun 12 16:53 media/

 

[Frank1940]

31 minutes ago, DTMHibbert said:

just tried to copy a file to the share and the permissions changed immediatley to 

Was this a copy from a Windows computer to the server using Windows Explorer  (Windows default file manger)?    Were you copying to a share-mapped-as-a-drive or navigating to the share on the server using Windows Explorer?

[DTMHibbert]

Yea, this was using windows explorer copying a file from desktop to the share which is mapped as a network drive "Z" 

 

one thing to mention which i dont know if this matters is i use a rootshare (SpaceInavders Video) this is currently set as so under SMB settings

[rootshare]
path = /mnt/user
comment =
browseable = yes
# Public
writeable = yes
vfs objects =

note its currently set to public as im trying to diagnose this issue. 

[Frank1940]

3 hours ago, DTMHibbert said:

this is currently set as so under SMB settings

[rootshare]
path = /mnt/user
comment =
browseable = yes
# Public
writeable = yes
vfs objects =

Above is yours:    

 Below is mine:

[Backup]
        path = /mnt/user/Backup
        comment = Created to allow for More Secure backups
        browseable = yes
        # Secure
        public = yes
        writeable = no
        write list =
        case sensitive = auto
        preserve case = yes
        short preserve case = yes
[Data]
        path = /mnt/user/Data
        comment = Pimax Files
        browseable = yes
        # Public
        public = yes
        writeable = yes
        case sensitive = auto
        preserve case = yes
        short preserve case = yes

Mine came from the   /etc/samba/smb-shares.conf   file.  Notice that the 'path' variable contains the share name!   This may present a problem but I am not sure what the ramifications are at this point.

 

Let's try another experiment.  First, fix the permissions.  Then, open up a Windows Explorer window to your media share (as shown below) and drag-and-drop a file from a folder on your Windows computer to the share in the Explorer window.  (Media is the share  and Family DVD Videos is a folder in that share.)

 

Now look at the permissions.

 

 

EDIT:  I know the settings on my Backup share might look a bit odd but there is some method to the madness.  For what is going on, read here:

 

 https://forums.unraid.net/topic/58374-secure-writing-strategy-for-unraid-server-using-write-once-read-many-mode/#comment-572532

Edited June 12, 2020 by Frank1940

[Frank1940]

@SpaceInvaderOne, Would appreciate if you would look over this thread as it appears that @DTMHibbert followed one of your recommendations about creating a {rootshare].  That may not be causing his problem at this point but I thought you might also have some thoughts on his current issue since  (apparently) you have some knowledge on the inter-workings of SMB .

[DTMHibbert]

2 hours ago, Frank1940 said:

Let's try another experiment.  First, fix the permissions.  Then, open up a Windows Explorer window to your media share (as shown below) and drag-and-drop a file from a folder on your Windows computer to the share in the Explorer window.  (Media is the share  and Family DVD Videos is a folder in that share.)

so i tried as you suggested, 

Before

root@Zeus:~# ls -alh /mnt/user
total 56K
drwxrwxrwx+  1 nobody users   58 Jun 12 23:39 ./
drwxr-xr-x  13 root   root   260 Jun 11 09:14 ../
drwxrwxrwx   1 nobody users  132 Jun 12 23:38 media/

After 

root@Zeus:~# ls -alh /mnt/user
total 52K
drwxrwxrwx+  1 nobody users   68 Jun 12 23:39 ./
drwxr-xr-x  13 root   root   260 Jun 11 09:14 ../
drwxrwx---+  1 nobody users   22 Jun 12 23:38 media/

and this is the permissions inside the media share of the folder i dropped the file into.

root@Zeus:~# ls -alh /mnt/user/media
total 40K
drwxrwx---+ 1 nobody users  22 Jun 12 23:38 ./
drwxrwxrwx+ 1 nobody users  68 Jun 12 23:39 ../
drwxrwxrwx+ 1 nobody users  26 Jun 12 23:41 Test\ Folder/

I dropped the file into the Test Folder, which is inside the media share - as shown the permissions look ok barring the "+" however if i navigate direct to that folder from windows explorer i can see my file - if i try accessing via the media share first i cant.

 

Thanks for you help so far in trying to diagnose this - im thinking of upgrading to 6.9.0 in case ive ran into some wierd glitch that updating might solve, what do you think?

 

my other thought is that seen as though i created another share which seems to work perfectly - can i create another share copy all my folders/ files from one to another then delete the old share...

[Frank1940]

26 minutes ago, DTMHibbert said:

Thanks for you help so far in trying to diagnose this - im thinking of upgrading to 6.9.0 in case ive ran into some wierd glitch that updating might solve, what do you think?

At this point, I  suspect that you have changed the Security settings on the Mapped Network Drive  (Z:).    The (very) few times I have played with the security settings on Windows Shared folders, I have found it to be a confusing mess,  There may be some rules to setting them somewhere but I never found them. 

 

(NOTE:  My experience with security setting was trying to limit access to a Shared Windows folder in which case the Windows computer is a server.  I can not picture a reason why one should want to limit access using the security setup on a Windows clients to a server shared source.  If that is required, the required security should be implemented on the server side of the equation.)

 

(NOTE 2:  I try to run my server and our personal PC's on a trusted LAN.  Everything else --- guests, IOT devices-- is on VLAN's which do not have access to the trusted LAN.) 

Edited June 12, 2020 by Frank1940

[DTMHibbert]

Not sure if i found anything of great importance but ive been digging around the diagnotics download and if i look in the share folder at the effected shares where this behaivor is happening the .cfg file just contains 

# This share has default settings.
# Share exists on cache,disk1,2,3,4,5,6,7

where by if i look at shares that arent effected by this behaivor they look more like config files... for example

# Generated settings:
shareComment="..."
shareInclude=""
shareExclude=""
shareUseCache="yes"
shareCOW="auto"
shareAllocator="highwater"
shareSplitLevel=""
shareFloor="0"
shareExport="e"
shareFruit="no"
shareCaseSensitive="auto"
shareSecurity="public"
shareReadList=""
shareWriteList=""
shareVolsizelimit=""
shareExportNFS="-"
shareExportNFSFsid="0"
shareSecurityNFS="public"
shareHostListNFS=""
shareExportAFP="-"
shareSecurityAFP="public"
shareReadListAFP=""
shareWriteListAFP=""
shareVolsizelimitAFP=""
shareVoldbpathAFP=""
# Share exists on disk5

dont know if this is worth looking into?

[Frank1940]

I had a look at the share folder in your Diagnostics file.  As you know, it contains only the first and last letter of each share. So my observation may not have relevance depending on what you find.  Below is a portion of the directory of that folder:

 

 

Notice that it appears that there are two shares with what appear to be two identical names except for capitalization.  This is a problem in all mixed Linux/Windows environments because Windows ignores capitalization and Linux embraces it!   As an example, Test.txt  and test.txt  are two separate and unique files to Linux.  Windows will recognize only one of them and completely ignore the other.  (The recognized one will be the first one found as I understand it.)   

 

You have at least seven of these cases...

 

This has often caused problems for users of Unraid because they will often setup a Docker and do not honor the capitalization of the Share name when setting in the Linux path in their Docker configuration.  When the Docker can't find the directory with that exact path name, it creates a new directory which results in new share.  Now Windows will only see one of those shares, so now there are missing files.