jeffreywhunter Posted November 10, 2016 Share Posted November 10, 2016 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 Quote Link to comment
jeffreywhunter Posted November 11, 2016 Author Share Posted November 11, 2016 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... Quote Link to comment
Frank1940 Posted November 11, 2016 Share Posted November 11, 2016 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? Quote Link to comment
jeffreywhunter Posted November 11, 2016 Author Share Posted November 11, 2016 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? Quote Link to comment
Frank1940 Posted November 11, 2016 Share Posted November 11, 2016 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.) Quote Link to comment
jeffreywhunter Posted December 14, 2016 Author Share Posted December 14, 2016 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? Quote Link to comment
Frank1940 Posted December 14, 2016 Share Posted December 14, 2016 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. Quote Link to comment
jeffreywhunter Posted December 14, 2016 Author Share Posted December 14, 2016 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... Quote Link to comment
Frank1940 Posted December 14, 2016 Share Posted December 14, 2016 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!!!) Quote Link to comment
Ph9214 Posted December 14, 2016 Share Posted December 14, 2016 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... Quote Link to comment
jeffreywhunter Posted December 16, 2016 Author Share Posted December 16, 2016 (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? Quote Link to comment
Ph9214 Posted December 16, 2016 Share Posted December 16, 2016 (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 Quote Link to comment
Frank1940 Posted December 16, 2016 Share Posted December 16, 2016 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!!!) Quote Link to comment
trurl Posted December 16, 2016 Share Posted December 16, 2016 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. Quote Link to comment
jeffreywhunter Posted December 24, 2016 Author Share Posted December 24, 2016 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! Quote Link to comment
jeffreywhunter Posted December 24, 2016 Author Share Posted December 24, 2016 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? Quote Link to comment
Frank1940 Posted December 24, 2016 Share Posted December 24, 2016 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!!!! Quote Link to comment
jeffreywhunter Posted December 24, 2016 Author Share Posted December 24, 2016 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? Quote Link to comment
Frank1940 Posted December 24, 2016 Share Posted December 24, 2016 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... Quote Link to comment
jeffreywhunter Posted December 24, 2016 Author Share Posted December 24, 2016 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] Quote Link to comment
Frank1940 Posted December 25, 2016 Share Posted December 25, 2016 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... Quote Link to comment
Frank1940 Posted December 25, 2016 Share Posted December 25, 2016 By the Way, the "New Permissions (Docker Safe:)" tool is a part of the fix.common.problems plugin. Sorry about that... Quote Link to comment
jeffreywhunter Posted December 25, 2016 Author Share Posted December 25, 2016 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... Quote Link to comment
Squid Posted December 25, 2016 Share Posted December 25, 2016 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. Quote Link to comment
jeffreywhunter Posted December 25, 2016 Author Share Posted December 25, 2016 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... 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.