File Transfer results in Error 0x8007003B

[AndyT86]

Ok! I found my problem.

I tried lots of things, so I am not sure what worked.

I switched from SAMBA to NFS.  Following this link someone linked:

https://graspingtech.com/mount-nfs-share-windows-10/

 

Though the bigger issues were this:

 

The exports are NOT //SERVER/share_name (though confusingly this did work sometimes...)

Instead they are //SERVER/mnt/user/share_name !  

This may be a difference in SAMBA vs. NFS.  And it also differs for all my other experience sharing things across the network. Admittedly, this is mostly SAMBA related.  I wonder if what happened is that this nomenclature works for SAMBA, but not for NFS.  Someone with more experience can clarify this.

 

Step by step I did the following:

 

On the WINDOWS client from a command prompt (importantly - NON- administrator- running as ADMIN will make the share incompatible with the Explorer GUI which runs in User mode by default, though the share exists in the CLI).

 

>NET USE
OK           V:        \\192.168.1.xxx\config    Microsoft Windows Network
Disconnected           \\169.254.0.xxx\rA          Microsoft Windows Network
Disconnected           \\UNRAID\Seagate_Expansion_Drive             Microsoft Windows Network
OK                     \\UNRAID\IPC$             Microsoft Windows Networ

NOTE here- share V: which goes to another computer, works reliably with the share \\SERVER\shared_dir

 

I probably wont black out all the personal data because its more work than its worth- youd have to find me first.  And some of these are direct client to client connections (no switch/router).

 

Delete all traces

 

 

>NET USE /DELETE \\169.254.0.2\rA
>NET USE /DELETE \\UNRAID\Seagate_Expansion_Drive
>NET USE /DELETE \\UNRAID\IPC$

ping UNRAID
#its connected.

>mount -u:user -p:password \\UNRAID\sharename\ A: 
#NFS requires a mount point, and that this CLI not be ADMIN
Network Error - 31

>NET HELPMSG 31
A device attached to the system is not functioning.

## Error 1: On the SERVER side, in log: tail var/log/syslog or w/e
<Date> Unraid rpc.mountd[6459]: refused mount request from <IP> for /share_name/ (/rA): unmatched host

Two things to fix this:

1) Add my desktop to /etc/hosts
 

127.0.0.1       Unraid localhost
54.149.176.35   keys.lime-technology.com

#direct 10gb connection IP
169.254.0.xxx     DESKTOP

#LAN 1Gb Connection
192.168.1.25    DESKTOP

I suspect the issue was mostly specific to my own setup, as I had previously done work in Routes to really get the system to prefer the 10Gb connection over the 1Gb connection, but use the LAN connection for everything else.

That is its whole own article.  

I generally take notes when working on unfamilar things, so I remember what I did, as trouble shooting always involves changing a slew of things, some of which make it worse. I can share that too. 

Note, these things for now dont seem persistant.  Will have to work on that down the road.

 

2) 

run `exportfs` to see the shared folders

Mine is set to private, so I need to authorize it. 

 

[More on NFS](https://wiki.archlinux.org/index.php/NFS#Server)

 

edit /etc/exports

 

by default it has:

         "/mnt/user/rA" -async,no_subtree_check,fsid=100 *(sec=sys,rw,insecure,anongid=100,anonuid=99,all_squash)

 

#need to allow my IP to connect

"/mnt/user/rA" -async,no_subtree_check,fsid=100 DESKTOP 169.254.0.0/255.255.255.248 192.168.1.0/24

 

I am fairly sure this needs to be fixed for both Samba/SMB and NFS.

 

So we give after the params the space delimited list of allowed connections.  You can only put host names and networks here.  Plain IPs dont work.  Though maybe <IP>/32 or <IP>/31 would work.  In theory Hosts should have fixed this, but I changed this before all the other pieces fell into place and maybe this is needed, maybe not.  Need something there though.

 

Neet to restart NFS and SAMBA each time you change the inner workings to get it to pick up. 

 

/etc/rc.d/rc.nfsd restart
# or
 /etc/rc.d/rc.samba restart

Now we get a new error:

 

  <Date> Unraid rpc.mountd[29835]: refused mount request from 169.254.0.1 for /IPC/ (/): not exported

 

Went back to Net USE and deleted a NFS share I briefly had working. I think that one I added in administrator CMD prompt.

 

NET USE /DELETE  A:

Note: this is named by its mount point, not its share point in NFS.  "NET USE /DELETE //server/share" didnt work.

 

Tried a LOT of other things. then tried the below based on [this](https://ubuntuforums.org/showthread.php?t=2055587)

 

One of the symptoms I got, which was bizarre was that clicking on (on the Client/Windows) /rA/some_sub_directory was giving me files that either A) read the entire volume of that sub-directory as a single file. So say .../rA/1 has no sub-dirs and 700gb of smaller files inside.  I would see 1 as a file, with size of 700gb.  Creating dummy directories helped...some, but no fix.

 

B) clicking another folder- .../rA/2 gave me a sibling of rA, not a sub-directory.  e.g. /mnt/user/isos and /mnt/user/rA are siblings.  Clicking /mnt/user/rA/2 gave me the contents of /mnt/user/isos.

 

Both of these were odd.

so in essence- adding a share of \\UNRAID\rA didnt totally not work, it just mostly didn't work.  Adding a share of \\UNRAID\mnt\user\rA\ works, for now.  Though its noticably slower than the SMB share I had working previously at \\UNRAID\rA.

 

Im not sure if enabling NFS broke this, (hole in my notes here) but I don't think I would have messed with that setting until AFTER it stopped working.

 

>mount --u:user -p:password \\UNRAID\mnt\user\rA\ A:
A: is now successfully connected to \\UNRAID\mnt\user\rA\

 

This works. For now.  Throughput is slower than I expected.  A lot of latency.  Creating a directory can take upwards of 20 seconds.  Was getting 200mb/s and up to 1Gb/s before, but I think that might be due to some tweaking I need to do on the drive /cache side.  Further opening "My Computer" now takes 30 seconds or more, as I wait for it to query the Server, authenticate, and enumerate space.  Something a raspberry pi completes in < 3 seconds.  (I have an 16 core server with 128Gb of RAM and 10Gb NIC- so this is a configuration issue).
 

There was a 3rd error from the log, I wish Id kept a snippet of, to help others who google these error messages and find loads of nothing and other people asking for help on the internet, and bring them here.

 

Ill add to this as I find out more if I remember.

 

I think the underlying issue here is two bits of code or libraries cobbled together, one which expects one format, and another which expects another format, and interoperability is broken.  Here-in is the down-side of closed source.  I can't figure it out, have to wait until LimeTech does.  I will eventually have to track down these issues.  Right now, transferring files onto the server says 88:37.48 s remaining, and 9.5 days remaining respectively.  It should be more like 2 or 3 hours.  12 hours at the outside if things are slow. So there's that.  Its working at the moment, and I have other things I need to do.

 

Edited November 4, 2020 by AndyT86

[AndyT86]

I want to point out again, that it seems like the edits to /etc/hosts and /etc/exports and also some changes I had to make to Routes and ifconfig are NOT persistent.  So these are bodges at best.  Rebooting is a pain.  Maybe someone can help me make things persistent.

[trurl]

21 hours ago, AndyT86 said:

edits to /etc/hosts and /etc/exports

The Unraid OS, including all the usual linux folders such as /etc, is in RAM. The flash drive only contains the archive of the OS. It is unpacked fresh into RAM at each boot. No changes are applied to that archive. It only changes when you update Unraid to a new version.

 

Any change you make to the OS folders must be reapplied at boot or it won't persist. The User Scripts plugin can help with this.

 

All this is just provided as general information. Not sure what your specific problems are. Most people don't require these hacks.

[Unknownkwita]

Incase it is useful for others, this error stopped occuring for me after I:

• disabled bonding NICs on unraid,
• mapped the share to windows 10 and
• Disabled docker
• Disabled VM
• disabled the secondary NIC on my windows computer.

 

It was a fresh install of unraid. No issues transferring small files like MP3s, but it didnt like my bluray rips that were ~20GB to 60GB. Error occured using windows file explorer to copy and Free File Sync.

Edited November 27, 2020 by Unknownkwita

[Unknownkwita]

On 11/27/2020 at 11:11 AM, Unknownkwita said:

this error stopped occuring for me after...

I Spoke too soon. i am getting this error with a vengence.

[etegration]

dec 2020, it's still the same. this problem is going to outlast the pandamic.

[etegration]

this worked for me...for now. i use robocopy with multithreaded MT:32, i reduced it to 4 and it has ran twice throughout the last 24 hours with no more network errors. i has got to do with windows/ nfs etc. I tried using the built in FTP server in unraid and there was no error but the same set of files will take 5 days to copy asFTP is single threaded with winscp scripting.

Edited December 23, 2020 by etegration

[NinjaGeoff]

I had this issue and finally fixed it by downgrading to 6.7.2 (Tools > About/Update OS). I was then able to transfer to my UNRAID server again. After I uploaded a 20 GB file, I upgraded to 6.8.3 again, and it's working as expected.

 

I had tried all the different recommended settings in Windows 10 (this was even on a fresh install of 10 Pro) as found in the link elsewhere in this thread, tried multiple different Windows 10 machines, verified they could send and receive files to each other, and ran the Docker Safe App Permissions tool, none of which helped. I wish I had thought to use a linux machine to try to upload a file to the share, but I didn't think of it until after I did the downgrade to 6.7.2.

[dielectric]

I was able to solve the problem I believe, simply turn off SMBv1 (aka Netbios) completely in Unraid. Settings > SMB Settings > Enable Netbios: No.

Once I turned that off I was able to transfer my large files without this error message 0x8007003b. I also got a nice solid 110-111MBps sustained throughput.

[dyker]

TLDR:  Check you Windows 10 Driver to ensure you have the up-to-date from manufacturer and NOT the rando Microsoft NIC driver.

 

Found this thread through a web search as I was having same error code when transferring a 100GB file.  Tried all the things then finally looked at my driver on my Windows 10 Dell system.  It's a Realtek PCIeGbE Family controller.  And guess what the driver loaded on my win 10 rig was provided by Microsoft dated 2015.  Well I run Dell's support Assist monthly and this software is SUPPOSED to keep my drivers fresh (and often does) but apparently it ignores the NIC driver.  Because when I visited https://support.dell.com for my system I found a driver provided by Realtek on the support page for my system (dated 8/11/2017).  After loading this driver the error went away and also the transfer rate stays solid... doesn't fizzle to nothing looking like an occasional heart-beat. 

 

This is a dynamic issue however in my case it definitely was a problem on the Windows 10 side of the house not the Unraid side of the house.

Edited May 2, 2021 by dyker

[hammsandwich]

I have noticed I set shares to public they work without issue.  When a share is private, I cannot copy anything larger than a few MB without a transfer fail.  Retry works about 1/5 times. This is prevalent on multiple Win10 machines on my network, all various versions with various hardware types.  Unfortunately having a mix of Public and Private shares also does not work because Windows does not allow for multiple connections to the same SMB servers with different accounts simultaneously. 

[itimpi]

1 hour ago, hammsandwich said:

Unfortunately having a mix of Public and Private shares also does not work because Windows does not allow for multiple connections to the same SMB servers with different accounts simultaneously. 

Not sure what you mean by this.    Why do you need multiple accounts since any user you can use for Private shares will also be able to connect to Public shares.

[hammsandwich]

Just now, itimpi said:

Not sure what you mean by this.    Why do you need multiple accounts since any user you can use for Private shares will also be able to connect to Public shares.

It is not multiple accounts. but multiple share types. 

 

For example, share "ABC" is set to Public, and share "XYZ" is set to Private, with R/W perms for user "123".

 

If I browse via Windows to \\unraid\ABC, I am immediately allowed in as an anonymous user and can read and write to share "ABC" perfectly fine.  Then I want to authenticate to share "XYZ" to work on more sensitive data.  I get prompted with username/password, and when entered correctly, Windows throws an error saying it cannot access different shares with multiple accounts on the same file server.  I am assuming this means it is counting the Anonymous user as a user.  I have been messing around this this all day and currently cannot reproduce this issue but am unable to at the moment. 

 

It is possible that changing the permissions of each share from private to public and back to private has resolved my issues...  This has been going on for the past 2 years or so I have finally gotten tired of it and am trying to fix the issue.

 

 

[itimpi]

You need to connect first to the Private share(s) before any Public shares and it then works without problems.    You will then connect to the Public shares using the same username as used for the Private ones.

[Chamzamzoo]

On 4/20/2021 at 4:57 AM, dielectric said:

I was able to solve the problem I believe, simply turn off SMBv1 (aka Netbios) completely in Unraid. Settings > SMB Settings > Enable Netbios: No.

Once I turned that off I was able to transfer my large files without this error message 0x8007003b. I also got a nice solid 110-111MBps sustained throughput.

This also fixed it for me. Thanks!

[Xochipelli]

I've been transferring (25+) TBs of files over the last week and this is my first time encountering this error.
Was initially using MC in terminal to transfer, and had 5 random files fail in transfer on this last job.
In testing, in terminal itself (not in MC), I was able to easily copy files to various directories on the same drive. As soon as I attempted to copy to a different drive, copy failed again.

Archived failed files individually in tar.gz, and moved to separate drives with no issue.

 

Maybe this info helps someone else

[shalamigri]

Well, I found what triggers this error. If you're doing a file transfer on a Windows PC while fiddling around with settings in the UI, this error will pop up as soon as you hit the apply button to apply whatever settings changes you've made.

Edited November 13, 2023 by shalamigri

[itimpi]

27 minutes ago, shalamigri said:

Well, I found what triggers this error. If you're doing a file transfer on a Windows PC while fiddling around with settings in the UI, this error will pop up as soon as you hit the apply button to apply whatever settings changes you've made.

That would be explain things as changing settings can cause the Samba sub-system to be restarted thus causing any transfers in progress to be aborted.