Access Denied but TSC confirms it should not be.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Please include the information requested at https://wiki.ubuntu.com/DebuggingSamba#samba-client.

I routinely use its IP address when accessing this server from my Ubuntu box. Windows, of course, uses DNS or netbios name resolution.

I ran the smbclient -L test twice - once in each mode. I did this in a few spare moments at work, and have only just looked in detail at the results.

The two results are interestingly different.

If my memory cells hold out until Monday, I will run the test again to see whether the error messages on the IP-access try are repeatable, or whether they are the kind of ephemera that make bug-hunting difficult.

Details are in the attachment.

Chris

Oops - My screenshot shows that both TSC and OOo were using the server name. I have probably put HBS_NTserver3 in my hosts file... I will check that also.

The smbclient -L test consistently gives an error message when addressing my server by its IP address. I will open this as a separate bug.
To avoid red herrings, my /etc/hosts file did not have an entry for the server. Access by name used a name resolution service.

Is there anything in your log files when this happens?

Can you set the debug level to 3 and attach the output?

Thanks
chuck

Assuming 'this' is the Access Denied issue...
I will check the server event log in the morning. The backup concerned is multi-gigabyte and takes nearly five hours. Needless to say it runs overnight.
I will run it tomorrow with debug level 3 assuming my aged memory cells remember after work tomorrow. I don't know from memory how many thousand files are involved, and the problem is on the W folders at the back end of the alphabet. If you have any suggestion about how big the level 3 log is per 1000 files it might help me to make sure there is enough disk space on the client. I might need to relocate the log file away from the crowded 20Gb system drive onto the large backup drive. But I'll try anyway if you can't get back.

Chris

PS If it is the smbclient -L bug, I now have a number for it, viz 437944.

C

Sorry for the delay - day job intruded.

The server event log has nothing near the time in question, and nothing I can relate to Access Denied.
No problem with /dev/sda size - except my geriatric amnesia.
To avoid red herrings, my /etc/hosts file did not have the server name; name resolution must have been used.
Debug level 3 set in client smb.conf but nothing found in /var/log/samba.

I have restarted the client (sadly following an Ubuntu update that included a Samba security fix....) and will recheck the backup and system logs when I go back in.

Backup still showing the same problem of Access Denied. There is nothing in /var/log/samba. Smb.conf log level says it is for logging samba server errors, and I'm only using the client. Have I been looking at the wrong config file (I can't see one for smbclient) or is there a log file elsewhere I should be looking for. I can't see one.

Hi,

Can you add the following "-d 9" to you smbclient command line and attach the output?

Thanks
chuck

Attached.

Cheers - and thanks.

Chris

Oops - I had forgotten there are two threads. The last upload belongs with 437944 - I have posted it there as well so this one can be deleted.

I will run the backup with the same log level tomorrow (Friday) assuming I remember... but it really will be really big - there are a lot of files in the backup.

Chris.

OK - but log.smbclient is 618.8 Mb. I have grep-ed it down to show that there is no match in the log for the file names that were not backed up. The upload includes the 200 lines preceding the occurrence of each file that was backed up from the directory in question. If 200 isn't enough I can easily extend it.

Notes about the files in the tgz:
pdrive-backup shows what most of the other files are (They all accumulate history - you are probably only interested in the tail ends of these)
extractor is run to cut the log.smbclient down to size, and makes extracts.

Looks like it's the Windows share that returns access denied for some reason... Could you enable audit on the windows side and check the event log on WHY the access is denied ?

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!