Copy to smb share slow

No worries, I hope you get it sorted.

found some time to try it but for some reason i could not get it working.

//   /mnt/Qnap cifs credentials=/home/desktop/.smbpasswd,uid=1000,gid=1000,vers=3.1.1,_netdev,x-systemd.automount,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

[desktop@desktop-systemproductname home]$ mount -a
mount.cifs: permission denied

I can remember mounting with systemd was different. but cannot recap what to do.

got it working. but speeds are not getting better

no one any idea?
or is information missing?

bring this thread up :slight_smile:

Hi, sorry for the late reply - I didn’t get a notification for some reason. I’m a bit confused - do you mean you got systemd mounting working, or fstab? I think mounting with systemd unit would ultimately be the same as with fstab, but there is a guide for using systemd here if you wanted it still: Manjaro systemd mount units. On your post with mount -a I think your permission was denied because you would need superuser rights to mount that share as shown.

Did you check file transfers using something like dd, just to see whether the issue lies with your file manager? Do you use ACLs? These can incur a performance penalty.

1 Like
1 Like

i am losing my patience with this :face_with_symbols_over_mouth:

okay lets start from the beginning. I removed the entries in the fstab to do it via mount units.

So I did

[desktop@desktop-systemproductname ~]$ sudo nano /etc/systemd/home-desktop-Qnap.mount

with the following content:

Description=FreeNas Mount



the same credentials as used and proved via fstab previously.


[desktop@desktop-systemproductname ~]$ sudo systemctl daemon-reload


   [desktop@desktop-systemproductname ~]$ sudo  systemctl start home-desktop-Qnap.mount
Failed to start home-desktop-Qnap.mount: Unit home-desktop-Qnap.mount not found.

Again, have you ruled out the possibility that the issue lies with your file manager? I am aware of network transfer issues that can exist with file managers, so I think it would be good to eliminate that possibility. I have only used CLI on my BSD and Linux setups until recently, so I really have no experience of this, but it is something that can happen. Also, I am aware that using extended attributes and ACLs can incur performance hits - I do not use these myself, so have not compared the difference between Windows and Unix-derived systems in my home, but it again is something I recommend checking.

It is very difficult/time consuming to run through the many potential issues that can occur with networked setups without being present, but those are the two simple points that come to mind as things to check. If these make no difference, you will know that the fault indeed likely lies with your samba implementation on your system. I understand the frustration of things not working as expected, but as far as I can tell you have not yet looked at these points I have mentioned a couple of times now. Good luck.

i am happy that you help me, just general situation is a bit frustrating.

I tried the DD method with my fstab mount, I got 2mb/s

some screenshots from servers config:

I would think next logical step would be to get this mount units to work and try the speeds.

got the mount units to work… was in wrong directory :roll_eyes:

however speeds are getting better:

dd is still with 2mb/s slow

Ok, that seems strange to me for it to be slower with dd. There are some block size parameters that can be modified using, as well as to avoid buffer cache with synchronised I/O - what parameters did you use? I guess with your speed having picked up using systemd mount units that is not really of much importance though! Glad to see your speed is much closer to what you would expect now.

I do note that you have ACLs enabled - I believe the performance impact of using them is supposed to be minimal, but I have read conflicting reports on this over the years. I have them disabled on my setup, as I don’t really need them and POSIX permissions are fine for my use case. It is something you could perhaps look at.

I have my send and receive buffers set at 524288 on my NAS, with asynchronous I/O read and write both enabled for transfers over 1024. Have you had a look at tuning these, to see if you can tweak the performance a bit further for your current setup?

freenas has 3 options for sync
1= standard
2= synchron writes
3= asynchron writes

Standard is application based, in case an application request sync writes it will comply.
So I assume with DD it synchron writes and with thunar it async. writes

I would like to avoid touching the ACL. it was a nightmare to set this up.

Autotune defined those variables:

receive buffers seems the same as you mentioned.

Fair enough, if you have the permissions working as you wish with ACLs then probably best to leave well alone. In my smb4.conf I have aio read size = 1024 and aio write size = 1024, so if your FreeNAS setup provides application-based asynchronous I/O enabled then probably little difference between our setups if it’s working as intended. I would probably have a look and see what setting to asynchronous always on does for speeds, but otherwise I don’t think I have any other obvious performance-related tweaks that may be different between our setups then. As a side note, I am surprised that a systemd mount is faster for you than fstab, as I was under the impression that fstab entries were dynamically converted into units at boot time, so that is interesting.

What I meant with dd is that you could set something like this for example:
dd if=/NAS_MOUNT_POINT/TEST_FILE of=/dev/null bs=1M count=1024 iflag=dsync
Which seems to get me the best speeds in my tests. Some more info if of interest: dd invocation. It might be a useful way for you to measure performance impact of any changes you make to your system, could be quicker than using your file manager.

Best of luck.

1 Like

another improvement with aio set:
aio read size = 1024
aio write size = 1024

thanks for the hints!

Really pleased to hear it’s a lot better now, that’s great. I wonder whether the standard FreeNAS application-based asynchronous I/O was not kicking in previously (but perhaps was with Windows)?

I am interested to find out what the performance impact of enabling ACLs is now, so at some point in the week I’ll free up one of my router ethernet ports and do some A/B comparisons with my Manjaro laptop to see - I have Windows 10 installed on it too, so can do a proper comparison for my own curiosity.

Had a bit of time this afternoon, and enabling ACLs appears to cost me around 1% performance on wired 1 GbE connection so really negligible. I haven’t bothered to do a statistical analysis, so we are possibly within margin of error here. Still can’t really see much difference between Windows and Manjaro transfers either - disabled or not.

Just in case some of these other settings may improve performance, here are those from my smb4.conf that I commented as being performance tweaks for myself:

oplocks = yes
strict locking = no
aio read size = 1024
aio write size = 1024
read raw = yes
write raw = yes
large readwrite = yes
kernel change notify = no
getwd cache = yes
load printers = no
printing = bsd
disable spoolss = yes
printcap cache time = 0
printcap name = /dev/null

I assume FreeNAS likely comes with sensible defaults, and I collected these from various fora and guides when I set up my server many years ago (so may even be a little outdated), but just in case there’s something there that might be of use. Obviously don’t disable printers if you use print functions with samba though! Best of luck if you’re still looking to get the last bit of performance.

1 Like

actually this was one of the first points which I did check.
default ist “standard”, so application based sync/async.

i tuned it off (so it writes async)and did some measurements. speed was the same. tuned sync writes on almost 50% slower.

smb writes via thunar or via windows explorer seems to be both async. writes as per application.

thanks for the parameters. Will try them out!

since we have covered mounting my shares, my I raise this:



that 2nd Qnap folder is every 20-40s disappearing for 1-2 seconds.

it looks odd to me, that there is a folder and even more that it does this disappear/appearing thing all the time.

I am not sure, I have no experience of xfce and thunar. Have you cleared all references to the NAS mount from thunar, and now using only the systemd mount unit? Does your journalctl show anything that correlates with the disappearance? I do get that this is somewhat linked, but you may be better off posting a new question for this to get the best responses.