Skip to main content
Unix & Linux

Return to Answer

Bounty Ended with 500 reputation awarded by Hauke Laging
added 76 characters in body
Source Link
ram0nvaldez
ram0nvaldez
  • 691
  • 1
  • 4
  • 7

Server Side

You may consider the server side as well, we know it is a Windows share, but nothing more, it would help to know the windows and SMB version this particular case is using. The server configuration can make a big difference especially when not using the Windows OS as a client. You know, ever since the windows shares appeared, it has been a game of cat an mouse, with the Samba and other teams chasing the changes implemented by Microsoft, since it is a closed system, they are not compelled at all to disclose the new features.

Main differences

What are the differences between the ways how smbclient and mount.cifs access a Windows share?

smbclient was meant to be used as a command line utility to have access to a network resource, mount.cifs is normally used by root, invoked by the mount command when using a cifs filesystem type, when used in the /etc/fstab file it is used to have permanent access to a filesystem.

From the man page The main difference may be that mount.cifs ignores smb.conf completely

samba client tools like smbclient(8) honour client-side configuration parameters present in smb.conf. Unlike those client tools, mount.cifs ignores smb.conf completely.

smbclient is an old implementation of an old protocol, SMB was replaced by CIFS, supposedly, cifs has the considerations for a newer implementation.

So, it may be a good idea to use a recent implementation of the protocol, but you should check which of these implementations works better with the server version available.

Can they behave the same?

How can mount.cifs be made to behave like smbclient?

Since mount.cifs ignores the smb.conf file, all the configurations of such file should be expressed in the invoking command, say, the corresponding line in /etc/fstab. For instance, you are already considering the -U username option used in smbclient, but there are other configurations in the smb.conf thay you may check. Particularly the log configuration, where the error messages may be written, should be that one of the fstab file, not the smb.conf file, check dmesg, /var/log/boot, /var/log/messeges

You may consider the server side as well, we know it is a Windows share, but nothing more, it would help to know the windows and SMB version this particular case is using. The server configuration can make a big difference especially when not using the Windows OS as a client. You know, ever since the windows shares appeared, it has been a game of cat an mouse, with the Samba and other teams chasing the changes implemented by Microsoft, since it is a closed system, they are not compelled at all to disclose the new features.

What are the differences between the ways how smbclient and mount.cifs access a Windows share?

smbclient was meant to be used as a command line utility to have access to a network resource, mount.cifs is normally used by root, invoked by the mount command when using a cifs filesystem type, when used in the /etc/fstab file it is used to have permanent access to a filesystem.

From the man page The main difference may be that mount.cifs ignores smb.conf completely

samba client tools like smbclient(8) honour client-side configuration parameters present in smb.conf. Unlike those client tools, mount.cifs ignores smb.conf completely.

smbclient is an old implementation of an old protocol, SMB was replaced by CIFS, supposedly, cifs has the considerations for a newer implementation.

So, it may be a good idea to use a recent implementation of the protocol, but you should check which of these implementations works better with the server version available.

How can mount.cifs be made to behave like smbclient?

Since mount.cifs ignores the smb.conf file, all the configurations of such file should be expressed in the invoking command, say, the corresponding line in /etc/fstab. For instance, you are already considering the -U username option used in smbclient, but there are other configurations in the smb.conf thay you may check. Particularly the log configuration, where the error messages may be written, should be that one of the fstab file, not the smb.conf file, check dmesg, /var/log/boot, /var/log/messeges

Server Side

You may consider the server side as well, we know it is a Windows share, but nothing more, it would help to know the windows and SMB version this particular case is using. The server configuration can make a big difference especially when not using the Windows OS as a client. You know, ever since the windows shares appeared, it has been a game of cat an mouse, with the Samba and other teams chasing the changes implemented by Microsoft, since it is a closed system, they are not compelled at all to disclose the new features.

Main differences

What are the differences between the ways how smbclient and mount.cifs access a Windows share?

smbclient was meant to be used as a command line utility to have access to a network resource, mount.cifs is normally used by root, invoked by the mount command when using a cifs filesystem type, when used in the /etc/fstab file it is used to have permanent access to a filesystem.

From the man page The main difference may be that mount.cifs ignores smb.conf completely

samba client tools like smbclient(8) honour client-side configuration parameters present in smb.conf. Unlike those client tools, mount.cifs ignores smb.conf completely.

smbclient is an old implementation of an old protocol, SMB was replaced by CIFS, supposedly, cifs has the considerations for a newer implementation.

So, it may be a good idea to use a recent implementation of the protocol, but you should check which of these implementations works better with the server version available.

Can they behave the same?

How can mount.cifs be made to behave like smbclient?

Since mount.cifs ignores the smb.conf file, all the configurations of such file should be expressed in the invoking command, say, the corresponding line in /etc/fstab. For instance, you are already considering the -U username option used in smbclient, but there are other configurations in the smb.conf thay you may check. Particularly the log configuration, where the error messages may be written, should be that one of the fstab file, not the smb.conf file, check dmesg, /var/log/boot, /var/log/messeges

Source Link
ram0nvaldez
ram0nvaldez
  • 691
  • 1
  • 4
  • 7

You may consider the server side as well, we know it is a Windows share, but nothing more, it would help to know the windows and SMB version this particular case is using. The server configuration can make a big difference especially when not using the Windows OS as a client. You know, ever since the windows shares appeared, it has been a game of cat an mouse, with the Samba and other teams chasing the changes implemented by Microsoft, since it is a closed system, they are not compelled at all to disclose the new features.

What are the differences between the ways how smbclient and mount.cifs access a Windows share?

smbclient was meant to be used as a command line utility to have access to a network resource, mount.cifs is normally used by root, invoked by the mount command when using a cifs filesystem type, when used in the /etc/fstab file it is used to have permanent access to a filesystem.

From the man page The main difference may be that mount.cifs ignores smb.conf completely

samba client tools like smbclient(8) honour client-side configuration parameters present in smb.conf. Unlike those client tools, mount.cifs ignores smb.conf completely.

smbclient is an old implementation of an old protocol, SMB was replaced by CIFS, supposedly, cifs has the considerations for a newer implementation.

So, it may be a good idea to use a recent implementation of the protocol, but you should check which of these implementations works better with the server version available.

How can mount.cifs be made to behave like smbclient?

Since mount.cifs ignores the smb.conf file, all the configurations of such file should be expressed in the invoking command, say, the corresponding line in /etc/fstab. For instance, you are already considering the -U username option used in smbclient, but there are other configurations in the smb.conf thay you may check. Particularly the log configuration, where the error messages may be written, should be that one of the fstab file, not the smb.conf file, check dmesg, /var/log/boot, /var/log/messeges