This is the command I am running on startup to mount my remote share.

sudo -u nuzz smbnetfs ~/netmount -o smbnetfs_debug=5 -o smb_debug_level=5 -o log_file=~/logs/smbnetfs.log -o allow_other

I can browse my files on the network share just fine. However, when running a CMake job where the destination is on the share, the job hangs or goes very slowly, and files do not get written to disk. The smbnetfs.log file reads:

2016-01-02 17:44:16.758 srv(1942)->smb_conn_srv_read: errno=13, Permission denied 2016-01-02 17:44:18.779 srv(1943)->smb_conn_srv_read: errno=13, Permission denied 2016-01-02 17:44:18.801 srv(1944)->smb_conn_srv_read: errno=13, Permission denied 2016-01-02 17:44:20.822 srv(1945)->smb_conn_srv_read: errno=13, Permission denied 2016-01-02 17:44:22.838 srv(1946)->smb_conn_srv_read: errno=13, Permission denied

I also saw entries in the log file related to CMakeError.log, but no log file was ever written. My guess is that this file was attempted to be written, but it could not do so.

Browsing the folder while the cmake job is hanging is also very slow. It takes about 20-30 seconds for something to load.

I verified that my smbnetfs.auth is correct (changing it means I cannot login at all).

I verified that my user account is in the fuse group.

This problem does NOT occur when the source folder in cmake is on the share but the destination is on the local drive. The remote drive is a Windows 10 NTFS partition.

If I use the -s flag on smbnetfs (single-threaded mode) this problem still occurs.

Are there any more logs that can help shed some light?

  • What is ~/netmount? Is that a script you wrote? What does it do? Have you set up the share to give nuzz write access? – terdon Jan 3 '16 at 9:29
  • ~/netmount is the target location where the share becomes accessible after using the command – Nuzzolilo Jan 3 '16 at 19:16
  • Duh! Of course it is. Sorry. – terdon Jan 3 '16 at 19:17
  • The share is set up for the user "Admin" (on the remote network) to have full read/write access, and smbnetfs.auth uses the credentials for the "Admin" account. Locally, the user nuzz appears to have read/write access to the folders and I am able to manipulate the folders – Nuzzolilo Jan 3 '16 at 19:18
  • I've never used smbnetfs, I do these things through mount.cifs and/or fstab and specify rw access there. – terdon Jan 3 '16 at 19:19

By some bizarre stroke of luck, I found that this has something to do with the max_retry_count value in smbnetfs.conf. Setting this value to 0 (was 2) caused the slowness issues to disappear. However, the Permission denied errors still appear in smbnetfs.log. I will declare this solved for the purposes of this question but it seems like a bug report is in order.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.