On 5/26/2016 1:51 PM, Jeff Boyce wrote:
>
>
> On 5/26/2016 12:18 PM, Michael Stowe wrote:
>> On 2016-05-26 13:46, Jeff Boyce wrote:
>>> On 5/26/2016 4:57 AM, Michael Stowe wrote:
>>>> Perhaps simple sharing is turned on, perhaps the share name has been
>>>> transliterated to something else. You might want to try the
>>>> troubleshooting step of listing the actual share names:
>>>>
>>>> /usr/bin/smbclient -L //rdr-lat6540
>>>>
>>>>
>>> Well, it took a little variation of the smbclient command to get to
>>> what
>>> you are looking for, but here are the results.
>>>
>>> bash-4.1$ smbclient -L rdr-lat6540 -U robynr
>>> Enter robynr's password:
>>> Domain=[RDR-LAT6540] OS=[Windows 10 Pro 10586] Server=[Windows 10
>>> Pro 6.3]
>>>
>>> Sharename Type Comment
>>> --------- ---- -------
>>> ADMIN$ Disk Remote Admin
>>> C$ Disk Default share
>>> IPC$ IPC Remote IPC
>>> print$ Disk Printer Drivers
>>> Users Disk
>>> Domain=[RDR-LAT6540] OS=[Windows 10 Pro 10586] Server=[Windows 10
>>> Pro 6.3]
>>>
>>> Server Comment
>>> --------- -------
>>>
>>> Workgroup Master
>>> --------- -------
>>>
>>> So noticing that my that share on rdr-lat6540 is listed as C$ and not
>>> just C, as in my configuration file. I made the appropriate changes in
>>> the configuration file and now I get a different error. So I guess I am
>>> making progress, but it might be sideways instead of forward. Now my
>>> full error is:
>>>
>>> Running: /usr/bin/smbclient \\\\rdr-lat6540\\C\$ -U robynr -E -d 1 -c
>>> tarmode\ full -Tc -
>>> \\users\\robynr\\AppData\\Local\\Microsoft\\Windows\ Live\ Mail
>>> full backup started for share C$
>>> Xfer PIDs are now 8068,8067
>>> Domain=[RDR-LAT6540] OS=[Windows 10 Pro 10586] Server=[Windows 10
>>> Pro 6.3]
>>> tree connect failed: NT_STATUS_ACCESS_DENIED
>>> Domain=[RDR-LAT6540] OS=[Windows 10 Pro 10586] Server=[Windows 10
>>> Pro 6.3]
>>> tree connect failed: NT_STATUS_ACCESS_DENIED
>>> tarExtract: Done: 0 errors, 0 filesExist, 0 sizeExist, 0
>>> sizeExistComp, 0 filesTotal, 0 sizeTotal
>>> Got fatal error during xfer (No files dumped for share C$)
>>> Backup aborted (No files dumped for share C$)
>>> Not saving this as a partial backup since it has fewer files than the
>>> prior one (got 0 and 0 files versus 0)
>>>
>>> I would guess that the NT_STATUS_ACCESS_DENIED error is a
>>> permissions or
>>> sharing problem on the Win10 box, but I am not seeing what it might be.
>>> I have file and printer sharing turned on for the C$ share, and the
>>> firewall is currently turned off while testing this. What else
>>> should I
>>> be looking at?
>>>
>>> Jeff
>>>
>>> --
>>>
>>> Jeff Boyce
>>> Meridian Environmental
>>
>> At the risk of stating the obvious, if you must declare a workgroup
>> to retrieve a listing of shares, then it's likely that you must also
>> declare a workgroup to gain access to the shares. (Windows is usually
>> quite casual about workgroups, except when it isn't, so you might
>> just want to confirm you either don't need it for the listing, or add
>> it for the connection.)
>>
>> NT_STATUS_ACCESS_DENIED comes from a few places, note that you're
>> getting a failure to connect to the tree, so it's unlikely to be a
>> folder permission error, it's more likely something earlier in the
>> process, like authentication. This could be as simple as supplying
>> the incorrect password, to an older version of smbclient which is
>> fine with supplying the share list but refuses to negotiate SMB with
>> W10, which requires stronger hashes.
>>
>> smbclient has changed its options and syntax a few times over time; I
>> note that the -N switch does not appear in your backuppc command
>> line, which is probably correct, since in more recent versions of
>> smbclient, this apparently causes it to stop sending the password...
>> But I also do not see a password on that command line. If you didn't
>> cleanse it when you posted (which wouldn't be a terrible idea,
>> obviously) then I'd look there first, because that may mean it's not
>> being sent, which would explain that error.
>>
>>
>
> I am now doing an assessment of all the clients setup in backuppc and
> seeing some minor variations between clients, and what is working and
> what isn't. I am now noticing that I have another Win7 box that is
> giving the same NT_ STATUS_ACCESS_DENIED error as the Win10 box. A
> quick look at the backuppc configuration between the bad Win7 box and
> my own working Win7 box shows no difference other than the include
> directory. So I am going to have to do a more detailed look at this
> other Win7 box that is bad. All other Win7 boxes are working fine. I
> may setup a new Win10 box so I have another point of comparison.
>
> I notice that all of my working Win7 boxes do not declare a workgroup
> in the config. I used that command because that is what I found in my
> old setup notes. I may have to try to list the shares without the -W
> option and see what happens, and likewise take your suggestion and add
> it to the config and see what the results are.
>
> From my research I figured the NT_STATUS_ACCESS_DENIED error could
> come from several different issues. That is why I was having a hard
> time sorting this out. I also noticed the failure to connect to the
> tree statement and suspected it might be permissions issue, but I am
> certain of the passwords. My ideal hope was that someone here was
> going to tell me... oh yea, Win10 introduced X?X, so you just have to
> make this little change here and every thing will work again.
>
> I had the -N switch problem on my initial setup, and was able to fix
> that after a bit of research, so I know not to include it. I did not
> cleanse the password from the command line displayed in the error. It
> is not included in my configuration. I can try that test also, but it
> makes me wonder why all my other Win7 boxes (except the one) works
> without providing a password argument in the command line statement.
>
> I am going to have to do a better comparison between all the working
> and non-working clients to isolate what might be different on the
> non-working boxes. It still may be a backuppc configuration problem
> on my part, but I am not ruling out that it is an issue on the Windows
> side of things. Need more data. More suggestions are welcome also.
> Thanks.
>
> Jeff
>
Ok I solved all my backup issues, so this post will give a summary of
what worked for me and hopefully help others.
My issue appeared to be a combination of Windows networking
configuration settings and the BackupPC config settings. Using the
example of the bad Win10 box discussed previously with the share listing
shown below.
bash-4.1$ smbclient -L rdr-lat6540 -U robynr
Enter robynr's password:
Domain=[RDR-LAT6540] OS=[Windows 10 Pro 10586] Server=[Windows 10 Pro 6.3]
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
print$ Disk Printer Drivers
Users Disk
Domain=[RDR-LAT6540] OS=[Windows 10 Pro 10586] Server=[Windows 10 Pro 6.3]
I was unable to connect to the default C$ share for conducting the
backup. Trying to connect to the C$ share directory through smbclient
with a debug level setting of 5 gave me no additional clues. So I was
down to doing some intuitive trial and error. I switched BackupPC to
using the Users sharename that was listed and everything worked properly.
So then I turned my attention to the bad Win7 box that I had and started
making some comparisons to other boxes. Using smbclient to list the
shares on the bad Win7 box showed that there was a C$ share listed, but
not a Users share listed. Network discovery, and file and printer
sharing were turned on. In the Advanced Sharing Settings, once I turned
on Public Folder Sharing (making sure also that Password Protected
Sharing was also turned on), then the listing of shares via smbclient
included the Users share. Then re-setting the BackupPC configuration to
use the Users share and everything worked fine.
So in *almost* all of my desktop boxes that are backing up to BackupPC
they are using these same settings and the Users share. I am not sure
what is going on internally in the Windows networking that doesn't allow
smbclient to connect to the default C$ share, but I am sure that
something within Windows is stopping it. Now I said *almost* all of my
desktop boxes are behaving this way. The exception is my own desktop
system; BackupPC is using the default C$ share without any problem. On
this box I do not have the Public Folder Sharing turned on, and
therefore also do not see a Users share listed in the smbclient output.
However, this box is backing up to BackupPC perfectly fine. And a
cursory review of the network sharing options doesn't seem to find
anything pointing to why it works with the default C$ share. If anyone
has an idea, please enlighten me. Thanks.
Jeff
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
