Access problem with Windows App Access to unRaid SMB Share?

[jeffreywhunter]

I had a problem earlier this summer with a Windows 10 app accessing an unRaid 6.1.9 SMB share (access denied).  It was suggested that the problem resided with Windows implementation of SMB protocols being SMB3 and unRaid at SMB2 - and that 6.2 would solve that problem.  So I've waited for 6.2 to mature and just upgraded to 6.2.4.  I'm still getting the same error from the App.

 

180225 Delete File '//HUNTERNAS/documents/Dropbox/Camera Uploads/2015-12-17 18.36.30.jpg'
- ERROR: Cannot move destination file to history folder: //HUNTERNAS/documents/_gsdata_/_saved_/Dropbox/Camera Uploads/2015-12-17 18.36.30.jpg: Access is denied.  (error 5); Elevated MoveFile: server said: The specified server cannot perform the requested operation.  (error 58)

 

I'm running latest version of windows 10 Pro.  Latest version of the App (Goodsync Pro 10.1.8.5 (x64)).

 

I've attached my diagnostics log.  I've looked through the syslog, but don't see any errors appearing when the App gets the errors.  I can copy files with no problem to/from the PC to the same share that I'm accessing from Goodsync.  Do I need to do something to turn on SMB3?

 

Thanks in advance!

hunternas-diagnostics-20161109-1550_1.zip

[jeffreywhunter]

Hmmm, was hoping someone had an idea on this one.  I had hoped that SMB3 support would solve the problem...  Guess I need a different backup strategy...

[Frank1940]

Are you having any problems copying files using Windows Explorer?

 

If not, it sounds like the problem is within the application or its settings.  Have you checked with the forums for the product?

[jeffreywhunter]

I've turned on SMB3 in Windows 10.  Supposedly unRaid 6.2.x uses SMB3 now...

 

Transferring files using Windows File Explorer works fine, its the app that has problems.  According to them, its an SMB communication problem between their app and the unraid share.

 

William replied (2016/07/07 08:37 am EST)

yes, this is smb problem that results in these error messages.

if you dont want SMB problems, use GS Connect -- works much better

http://www.goodsync.com/for-linux

 

You wrote (2016/07/06 11:19 pm EST)

So perhaps its a permissions problem? Or is it an SMB v3 problem?

William replied (2016/07/06 01:08 pm EST)

ok, I see.  actually elevated GS does work, but it gets this

"error:server said: The specified server cannot perform the requested operation. (error 58)"

so it means that your share does not allow this operation (MoveFile)

even when client runs elevated.

 

- ERROR: Cannot move destination file to history folder: //HUNTERNAS/documents/_gsdata_/_saved_/Downloads/winx-dvd-copy-pro (1).exe: Access is denied. (error 5); Elevated MoveFile: server said: The specified server cannot perform the requested operation. (error 58)

2016-07-05 03:06:15 5994 [Documents to NAS] Delete File '//HUNTERNAS/documents/Downloads/winx-dvd-copy-pro.exe'

 

You wrote (2016/07/06 12:41 pm EST)

I had forgotten that there was the SMB support issue with windows 10. I had fixed the problem some time ago with a registry fix. Perhaps a new update of Windows has resurfaced the problem. Any thoughts on windows being the source of the problem? I know that Linux does not yet support SMB 3.x...

 

In order to run the Linux version, I have to create a Docker.  Not done that before, I'm not a Linux Admin and I don't play one on TV, so not chuffed about that option...

 

Thoughts?

[Frank1940]

I've turned on SMB3 in Windows 10.  Supposedly unRaid 6.2.x uses SMB3 now...

 

Transferring files using Windows File Explorer works fine, its the app that has problems.  According to them, its an SMB communication problem between their app and the unraid share.

 

William replied (2016/07/07 08:37 am EST)

yes, this is smb problem that results in these error messages.

if you dont want SMB problems, use GS Connect -- works much better

http://www.goodsync.com/for-linux

 

You wrote (2016/07/06 11:19 pm EST)

So perhaps its a permissions problem? Or is it an SMB v3 problem?

William replied (2016/07/06 01:08 pm EST)

ok, I see.  actually elevated GS does work, but it gets this

"error:server said: The specified server cannot perform the requested operation. (error 58)"

so it means that your share does not allow this operation (MoveFile)

even when client runs elevated.

 

- ERROR: Cannot move destination file to history folder: //HUNTERNAS/documents/_gsdata_/_saved_/Downloads/winx-dvd-copy-pro (1).exe: Access is denied. (error 5); Elevated MoveFile: server said: The specified server cannot perform the requested operation. (error 58)

2016-07-05 03:06:15 5994 [Documents to NAS] Delete File '//HUNTERNAS/documents/Downloads/winx-dvd-copy-pro.exe'

 

You wrote (2016/07/06 12:41 pm EST)

I had forgotten that there was the SMB support issue with windows 10. I had fixed the problem some time ago with a registry fix. Perhaps a new update of Windows has resurfaced the problem. Any thoughts on windows being the source of the problem? I know that Linux does not yet support SMB 3.x...

 

In order to run the Linux version, I have to create a Docker.  Not done that before, I'm not a Linux Admin and I don't play one on TV, so not chuffed about that option...

 

Thoughts?

 

Have you tried 'right-clicking' on the app and selecting 'Run As Administrator'.    (I suggest this because the app 'says' it is doing a 'move' operation which implies (to me) a copy-and-delete.) 

[jeffreywhunter]

Sorry, just found your reply.  Your idea prompted me to try some things.  Now it gets interesting.

 

I did the following with the indicated results.

 

1. Goodsync backup to Documents share fails - error 5 (access denied)

2. Goodsync backup to Movies share WORKS!

 

So this has to be a problem with the Documents share.  The ONLY difference between the share definitions, other than the share name, are the disks assigned.

 

http://my.jetscreenshot.com/12412/20161214-bbu1-241kb.jpg[/img]

 

Both shares use disks 1-5.  Documents uses 9, Movies uses 6 and 7 uniquely.

 

Ran syncs using Disk 9, 6 and 7 independently and even tried Disk 5. All worked bidirectionally (copy to/from both win/unraid) with no errors.

 

So this whole issue has something to do with this specific share.  Any thoughts on how to diagnose this issue?  What could be causing that ONE share to have access issues?

 

 

[Frank1940]

What happens if you setup a Temp share on the server, transfer the same set of files (which fail when copying to Documents) and see what happens then.

 

I am suspecting that it has something to do with some extended permissions on the files on the Windows end.  I have had problems in the past copying computer image files from of my Windows OS to the server.  I usually end up having to run the copy program as Administrator. 

[jeffreywhunter]

Soooo, its gets really weird.  I went through a bunch of gyrations and ended up recreating the share.  Same share config, everything identical except the share is now "documents2" vs "documents".  And the backup is working from within Goodsync from my win10 to unRaid via this new share NO PROBLEM?!?

 

What in the world could be causing that one share to not work?  Identical config?!?

 

So strange...

 

[Frank1940]

If you look on your C:\ drive on your Windows computer, You will find a 'Documents and Setting' folder.  Look through there and you will find under 'All Users' folder, a 'Documents' folder.  I would bet that Windows is treating the  "Documents" name as a special type of reserved name...

 

(I  have always had a rule that working with computers is a bit like playing a game where you don't know all of the rules.  That 'They' make the rules and you have to play by their rules!!!) 

[Ph9214]

yep it's probably the fact that the name is identical to a windows user folder name so try naming it Docs or whatever you feel like other than the standard user folders which include:

 

• Desktop
  
• Documents
  
• Videos
  
• Pictures
  
• etc...
  

[jeffreywhunter]

(I  have always had a rule that working with computers is a bit like playing a game where you don't know all of the rules.  That 'They' make the rules and you have to play by their rules!!!)

 

So-Very-True!!!

 

yep it's probably the fact that the name is identical to a windows user folder name so try naming it Docs or whatever you feel like other than the standard user folders which include:

 

I would agree that both you have identified the problem.  However, I did fix it (using the "documents" as a share name) by creating a new share (identical config) using Documents2, then verified it worked, then deleted the documents share, then renamed Documents2 to Documents.  And everything is working.

 

Given I agree with your assessments on the 'default' names, why would it now work?  Seems like as soon as I renamed Documents2 to Documents, the conflict should show-up again...

 

Thoughts?

[Ph9214]

(I  have always had a rule that working with computers is a bit like playing a game where you don't know all of the rules.  That 'They' make the rules and you have to play by their rules!!!)

 

So-Very-True!!!

 

yep it's probably the fact that the name is identical to a windows user folder name so try naming it Docs or whatever you feel like other than the standard user folders which include:

 

I would agree that both you have identified the problem.  However, I did fix it (using the "documents" as a share name) by creating a new share (identical config) using Documents2, then verified it worked, then deleted the documents share, then renamed Documents2 to Documents.  And everything is working.

 

Given I agree with your assessments on the 'default' names, why would it now work?  Seems like as soon as I renamed Documents2 to Documents, the conflict should show-up again...

 

Thoughts?

 

it may be that the actual path and not the name is still Documents2 I really have no idea, it could also be that somehow your share config just got messed up somehow

[Frank1940]

If our assessment was valid, the problem will rear its ugly head again when you can least afford to have it happen.  (Murphy's First Law!!!)

[trurl]

Sounds to me like maybe the permissions on the share were set wrong somehow, and creating a new share then renaming it resulted in a share that didn't have those permissions.

[jeffreywhunter]

If our assessment was valid, the problem will rear its ugly head again when you can least afford to have it happen.  (Murphy's First Law!!!)

 

Curse you Red Baron! 

[jeffreywhunter]

Sounds to me like maybe the permissions on the share were set wrong somehow, and creating a new share then renaming it resulted in a share that didn't have those permissions.

 

Is there a way, a log or some diagnostic I could check that might indicate that?

[Frank1940]

Login via PuTTY or the console and type

 

ls -al /mnt/user

 

That will give something like this:

 

drwxrwxrwx 1 nobody users  128 Dec 22 12:30 ./
drwxr-xr-x 6 root   root   120 Dec 22 12:30 ../
drwxrwxrwx 1 nobody users  472 Dec 13 15:46 Backup/
drwxrwxrwx 1 nobody users 1400 Dec 23 09:10 Media/

 

drwxrwxrwx 1 nobody users--- in this section, these are the permissions for that name.  the 'd' indicates that it is a directory and not a file (A file would be a  -  ).  The first block of rwx are the permission for the owner, the second bloc are the permissions of members of user group and the third block is the Public permissions.          nobody is the owner in this case and  users    is the user group. 

 

By the way, this is the default that you should find on all directories in this directory  /mnt/users.    Files will look like this:

 

-rw-rw-rw- 1 nobody users  171432901 Aug 10  2013 312D_FrenchSideTable.mp4

 

If you are a complete Linux Newbe, look up the following Linux commands:    cd  and    ls    Remember that Linux is case sensitive!!!! 

 

[jeffreywhunter]

I grew up with DOS "back in the day", so the command line isn't foreign, just different here in unRaid/linux land.  I use cd and ls frequently, but not messed with the options much.

 

root@HunterNAS:~# ls -al /mnt/user
total 20971608
drwxrwxrwx  1 nobody users          34 Dec 23 13:46 ./
drwxr-xr-x 15 root   root          300 Dec 23 13:46 ../
drwxrwxrwx  1 nobody users           6 Nov 12 19:14 Backup/
drwxrwxrwx  1 nobody users       24576 Aug 24 00:51 DeleteThisShare/
drwxrwxrwx  1 nobody users          24 Jul  2 09:01 Dropbox/
drwxrwxrwx  1 nobody users           6 Jul 17 18:27 Goodsync/
drwxrwxrwx  1 nobody users        4096 Dec 14 12:00 ISO\ Files/
drwxrwxrwx  1 nobody users         132 Apr 11  2016 Pydio/
drwxrwxrwx  1 nobody users         288 Dec 24 03:00 appdata/
drwxrwxrwx  1 nobody users         230 Nov  9 09:24 backups/
drwxrwxrwx  1 nobody users         121 Nov 12 19:12 cachebackup/
-rw-rw-rw-  1 nobody users 21474836480 Dec 24 03:53 docker.img
drwxrwxrwx  1 nobody users        4096 Dec 23 03:00 documents/
drwxrwxrwx  1 nobody users        8192 Dec 14 21:34 documents2/
drwxrwxrwx  1 nobody users          46 Dec 23 06:00 home\ movies/
drwxrwxrwx  1 nobody users          53 Sep 13 18:12 jwhbackup/
drwxrwxrwx  1 nobody users         114 Dec 23 12:01 movies/
drwxrwxrwx  1 nobody users        8192 Oct 28 12:57 music/
drwxrwxrwx  1 nobody users          34 Jul 10  2015 ndh/
drwxrwxrwx  1 nobody users          53 Dec 23 03:00 pictures/
drwxrwxrwx  1 nobody users         140 Dec 23 06:00 tv/

 

As you can see, both documents/ and documents2/ have been created recently.  I don't see anything diagnostic here with my semi-trained eye.

 

For good measure, here are the share setups for each...

http://my.jetscreenshot.com/12412/20161224-q9ez-133kb.jpg[/img]

http://my.jetscreenshot.com/12412/20161224-8us7-139kb.jpg[/img]

And the SMB output

http://my.jetscreenshot.com/12412/20161224-vu1k-230kb.jpg[/img]

 

All appears well?

[Frank1940]

Now, you can start down the tree for both shares.  I would start with a  cd /mnt/user  to put you in the /mnt/user directory.  Note that your current directory is  /mnt/user  is shown in the prompt in case you get lost.  (After you input a couple of commands, the up and down arrows will move up and down recent commands.)  Then do  cd documents  and you will see the you are now in  /mnt/user/documents. another  ls a-l  will show what the properties for each file and directory there.    (A  cd ..   will move back a directory level.)  Now navigate through both directory trees and see if you find anything unusual... 

[jeffreywhunter]

Now navigate through both directory trees and see if you find anything unusual...

 

The only oddity I have found is that in the old documents (documents2 now) directory, all the files and directories are set with user JWH, whereas in the new documents folder, about 90% of the files and directories are set to nobody users.  Rights appear to be identical between the two, but the owner is not...

 

http://my.jetscreenshot.com/12412/20161224-b4if-510kb.jpg[/img]

[Frank1940]

This will cause problems!!!!  As I understand it, the users 'nobody and 'users' have special properties that are required for unRAID shares.  If you go to 'Tools', you will see a 'New Permissions' tool. You can run that and it will fix the permissions.  Howver, I understand it causes problems if you have dockers installed.  So some wrote a ''New Permissions' tool which has the following help:

 

New Permissions

(Docker Safe)

 

This utility will restore standard unRaid permissions to all shares and files without touching any of the APPDATA shares for docker applications.

 

(Many times, a docker application has specific requirements for its ownership / permissions on the files contained within its appdata, and the standard New Permissions tool will change these, possibly rendering the docker application inoperable.)

 

You should use this tool in case a misconfigured docker application (notably CouchPotato or Sonarr / SickBeard) has written media files to your array with the wrong permissions, and you find yourself unable to modify / delete those files.

 

This utility starts a background process that goes to each of your data disks and cache disk and changes file and directory ownership to nobody/users (i.e., uid/gid to 99/100), and sets permissions as follows:

 

 

For directories:

  drwxrwxrwx

 

For read/write files:

  -rw-rw-rw-

 

For readonly files:

  -r--r--r--

   

 

The following shares will NOT be touched: Additional shares can be excluded HERE

 

appdata

 

Clicking Start will open another window and start the background process. Closing the window before completion will terminate the background process - so don't do that. This process can take a long time if you have many files. During this time, the webUI will be unavailable. If you do close the pop up window, the current folder in progress will be finished before the webUI is responsive again.

 

I suspect that one of your plugins or Dockers is misconfigured...

[Frank1940]

By the Way, the "New Permissions (Docker Safe:)" tool is a part of the fix.common.problems plugin.  Sorry about that...

[jeffreywhunter]

Ah, perhaps this is important.  I've run Fix Common Problems before.  Very helpful.  Your post made me go back again.  And behold, "The plugin docker.buttons.plg is not known to community applications and is possibly incompatible with your server.  "as a general rule...[dont use it!]"

 

I'll uninstall and see if that helps...

[Squid]

Ah, perhaps this is important.  I've run Fix Common Problems before.  Very helpful.  Your post made me go back again.  And behold, "The plugin docker.buttons.plg is not known to community applications and is possibly incompatible with your server.  "as a general rule...[dont use it!]"

 

I'll uninstall and see if that helps...

docker buttons was deprecated by gfjardim in favor of advanced buttons.

[jeffreywhunter]

Interesting, he just published an update on it...  I took a look for Advanced Buttons, but the only app in the CA is Docker Buttons...