Hi, I am trying to address some error messages that are hitting the log files for two 4.9.5-Debian file servers in our all-Samba AD domain. Most prominently "connect to service Profiles initially as user MYDOMAIN\tc-mj00y2ps$ (uid=11128, gid=10515) (pid 1634)" "../source3/smbd/uid.c:453(change_to_user_internal)" "change_to_user_internal: chdir_current_service() failed!" and "../source3/smbd/vfs.c:898(vfs_GetWd)" "vfs_GetWd: couldn't stat "." error Permission denied (NFS problem ?)" Looks like our Win boxes connect to the roaming profiles share with computer-account credentials initially. Other shares, such as 'Users', are being accessed with respective user credentials, and everything works as expected; ie., no "change_to_user_internal" error message. I am a bit hazy on the internals here, so before I dump config settings for all the usual suspects, my question is whether this is expected behavior for domain-joined machines? Windows ACLs on the 'Profiles' directory have been set according to the corresponding Samba Wiki article, including 'Full Control' for the 'System' account, and the above snafus don't seem to have any impact on performance. One quirk, though, is that we are relying on non-integrated bind9 zones at two different sites, setting the same A record alias for the respective file server's IP address (ie., 'legacybox' -> 192.168.55.2 @ site1; 'legacybox' -> 192.168.66.2 @ site2). This means that there are no SPN entries for 'legacybox', and all authentication against those shares is pure NTLMv2. Another observation is that, after a recent update, machine accounts do not show any longer in 'wbinfo -u' and 'getent passwd' listings. 'wbinfo -i [computer name]$' will provide mappings within the expected domain range (10000-999999), though. Again, I know just enough to be dangerous, so I am unsure as to whether the 'change_to_user_internal' error might be idmap related? Any pointers greatly appreciated! Mike
On 02/01/2020 05:30, Mike Ruebner via samba wrote:> Hi, > > I am trying to address some error messages that are hitting the log files > for two 4.9.5-Debian file servers in our all-Samba AD domain. Most > prominently > > "connect to service Profiles initially as user MYDOMAIN\tc-mj00y2ps$ > (uid=11128, gid=10515) (pid 1634)" > "../source3/smbd/uid.c:453(change_to_user_internal)" > "change_to_user_internal: chdir_current_service() failed!" > > and > > "../source3/smbd/vfs.c:898(vfs_GetWd)" > "vfs_GetWd: couldn't stat "." error Permission denied (NFS problem ?)" > > Looks like our Win boxes connect to the roaming profiles share with > computer-account credentials initially. Other shares, such as 'Users', are > being accessed with respective user credentials, and everything works as > expected; ie., no "change_to_user_internal" error message. > > I am a bit hazy on the internals here, so before I dump config settings for > all the usual suspects, my question is whether this is expected behavior for > domain-joined machines? Windows ACLs on the 'Profiles' directory have been > set according to the corresponding Samba Wiki article, including 'Full > Control' for the 'System' account, and the above snafus don't seem to have > any impact on performance. One quirk, though, is that we are relying on > non-integrated bind9 zones at two different sites, setting the same A record > alias for the respective file server's IP address (ie., 'legacybox' -> > 192.168.55.2 @ site1; 'legacybox' -> 192.168.66.2 @ site2). This means that > there are no SPN entries for 'legacybox', and all authentication against > those shares is pure NTLMv2. > > Another observation is that, after a recent update, machine accounts do not > show any longer in 'wbinfo -u' and 'getent passwd' listings. 'wbinfo -i > [computer name]$' will provide mappings within the expected domain range > (10000-999999), though. Again, I know just enough to be dangerous, so I am > unsure as to whether the 'change_to_user_internal' error might be idmap > related? > > Any pointers greatly appreciated! > > Mike >Sorry for a late answer to this, it got missed in the new year haze ;-) It looks like you are using the 'rid' backend and so your computers are being treated as users, so the log messages are an artifact of this. You can either ignore them, or set 'log level = 0' in smb.conf (which boils down to the same thing). Rowland
Hi Rowland, No worries. I appreciate the work you put in here. And, yes, this is the rid backend for domain idmap. No good deed goes unpunished, I guess :) My thinking is to allow 'Everyone' read access to the root of the share and see whether the error messages go away. There's just too much chatter in those log files right now. Bests, Mike On 02/01/2020 05:30, Mike Ruebner via samba wrote:> Hi, > > I am trying to address some error messages that are hitting the log > files for two 4.9.5-Debian file servers in our all-Samba AD domain. > Most prominently > > "connect to service Profiles initially as user MYDOMAIN\tc-mj00y2ps$ > (uid=11128, gid=10515) (pid 1634)" > "../source3/smbd/uid.c:453(change_to_user_internal)" > "change_to_user_internal: chdir_current_service() failed!" > > and > > "../source3/smbd/vfs.c:898(vfs_GetWd)" > "vfs_GetWd: couldn't stat "." error Permission denied (NFS problem ?)" > > Looks like our Win boxes connect to the roaming profiles share with > computer-account credentials initially. Other shares, such as 'Users', > are being accessed with respective user credentials, and everything > works as expected; ie., no "change_to_user_internal" error message. > > I am a bit hazy on the internals here, so before I dump config > settings for all the usual suspects, my question is whether this is > expected behavior for domain-joined machines? Windows ACLs on the > 'Profiles' directory have been set according to the corresponding > Samba Wiki article, including 'Full Control' for the 'System' account, > and the above snafus don't seem to have any impact on performance. One > quirk, though, is that we are relying on non-integrated bind9 zones at > two different sites, setting the same A record alias for the > respective file server's IP address (ie., 'legacybox' -> > 192.168.55.2 @ site1; 'legacybox' -> 192.168.66.2 @ site2). This means > that there are no SPN entries for 'legacybox', and all authentication > against those shares is pure NTLMv2. > > Another observation is that, after a recent update, machine accounts > do not show any longer in 'wbinfo -u' and 'getent passwd' listings. > 'wbinfo -i [computer name]$' will provide mappings within the expected > domain range (10000-999999), though. Again, I know just enough to be > dangerous, so I am unsure as to whether the 'change_to_user_internal' > error might be idmap related? > > Any pointers greatly appreciated! > > Mike >Sorry for a late answer to this, it got missed in the new year haze ;-) It looks like you are using the 'rid' backend and so your computers are being treated as users, so the log messages are an artifact of this. You can either ignore them, or set 'log level = 0' in smb.conf (which boils down to the same thing). Rowland -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba