See bug report 7164. I thought this problem was solved in 3.5.0rc3. Unfortunately it seems like there are still problems with this. Logout/login solve the issue, but since it is quite natural to use standby with a laptop and offline folders, I will consider this a serious problem.
Created attachment 5419 [details] SAMBA log file Here comes a log file from the server. I was initially attached from ulf-pc as NN, switched user to and the intention was to be connected as yy to another share. Something goes wrong, see [2010/02/25 06:04:12.308637, 0] smbd/nttrans.c:2200(call_nt_transact_ioctl) call_nt_transact_ioctl(0x901af): Currently not implemented.
Hm, it's something fishy here. Now I can't reproduce this problem with the same clients as I used yesterday. Offline folders get's online as soon as i resume from standby or switch user.However, the log-file still contains a lot of crap. This morning I couldn't get back online without logging out from the client account followed by a new login. I have also set up another client with Windows 7 (32bits). Seems to work OK as well. I will continue do tests with the two clients and jumping back and forth between different accounts and shares on both mashines.
Problem back again. This time with Windows 7 (32bit) client as well. Folder in offline status, but smbstatus on the server indicates client as well as share is connected. The log file is full of lines like this: [2010/02/25 22:32:23.598567, 1] smbd/service.c:678(make_connection_snum) create_connection_server_info failed: NT_STATUS_ACCESS_DENIED This is extremely frustrating. 3month after the official Windows 7 release this is still a problem with SAMBA!
Maybe I should moderate my language a bit, but honestly it is remarkable if I'm the only one fighting with this standby problem. I guess it should be one of the most common use cases with offline folders to use standby when you undock your laptop. But you need to have private shares as well to trigger this problem. Public folders does not impose any problems.
Not only is it remarkable, it's also intermittent even for you :-). You need to add a fully reproducible test case if you need this to be looked at seriously. (1). attach your smb.conf. (2). Describe your server environment (server OS, filesystems in use, mount options etc.). (3). Describe *EXACTLY* what you are doing on the Win7 box to reproduce this. A step-by-step receipe to reproduce the problem. No missing steps, no "and then this happens". I want a script to reproduce that even a moron (like myself :-) can follow. I'll start taking it seriously when you start taking the bug reporting seriously. Jeremy.
OK, point taken. This is my setup: A laptop running Samba 3.5.0rc3 (untouched) on Ubuntu 9.1. Server configured according to enclosed config file. A basic configuration, just two accounts nn and yy and two shares configured for private access. Note: I have not used the same user names and passwords as on the Windows accounts. I don't know if this is a prerequisite to reproduce my problem, but please not this. A Windows 7 Ultimate client. I have tried with 32bit version as well as 64bit, no difference. Problem can be reproduced with both platforms. You need at least two different accounts defined on the client. Test case: Start to login to the first account on the client. Map a drive to one of the Samba shares and make sure specifying "other credentials" when connecting to the share. User name must be specifed as SAMBA_LAPTOP\nn (or SAMBA_LAPTOP\yy) and also type in the SMBD password for that account. Mark the check box so the share will be automatically connected at logon. Copy a few files to the share (mapped drive) and mark for offline access. Windows will then automatically create offline sync copies of the files. Switch user (without logout) to another account on the client and repeat above mentioned setup, but use the other Samba share. After this, switch between the accounts and make sure both shares are available and online. Then force the client to standby. Leave the client in standby state for at least a couple of hours or over night. Resume the client and then you most probably will find the share in offline state. Switching between the two accounts will most often show also the other share in offline state. In some cases one of the shares could remain in online state. Checking the server with smbstatus indicates both accounts and shares connected to the server. I hope this description is accurate enough for you to look into this problem in more detail. Otherwise, please let me know what more info you need. The reason why I use this setup with multiple accounts is I use this setup on my desktop with multiple users. All user files is redirected to the NAS and I would like to have those folders to be members in the new library concept in Windows 7. Windows will enforce offline access in this case to make local copies of all files to make the indexing service work. Otherwise I have not bothered to enable offline access on a desktop computer. I also use Windows 7 on my family member's laptops, and in this case I'm dependant on the offline folder function to keep the local content in sync with the NAS.
Created attachment 5425 [details] Smb.conf
Thanks for the detailed reproducible test case. I'll take a look at this early next week. Jeremy.
One additional comment. It seems you must involve multiple accounts on the client to trigger this fault. I have just run a test with one single account, put the client in standby state, resumed after a couple of hours and everything seems to be ok. I have repeated this several times now and also left the client over the night. Still no problem.
Jeremy, did you have a chance to have a look at this one?
a lot of stuff changed in that area, this might even be a client bug or limitation. Without direct access to such a box this looks not debuggable also, we need to close this one finally.