If you are using the OMV standard Debian Wheezy 7.9.0 version of Samba (3.6) then you will only have SMB 2 capabilities. See this for background: https://en.wikipedia.org/wiki/Samba_(software)
I backported to Samba 4.1 and therefore I have SMB 3 capabilities.
I liked the guide. It has a few tips I hadn't seen yet. I was thinking of using a RAM drive for some of the items that use the cache directory (including the Samba cache), but I hadn't seen anyone else doing it and was therefore cautious.
Thanks for the information!
I am able to browse the server Samba share with explorer without problem. However, in the past (last half-dozen years) I know that at times Samba can be finicky about browsing the top level and it is sometimes easier to start by navigating to a share \\ip_of_server\shared_folder before going to the top level. I'm not sure why I sometimes have problems and they typically self-remedy or can't be reproduced.
2x Windows 10 Pro, 1x Windows 8.1 Pro
I am using a backported version of samba (4.1.17+dfsg-1~bpo70+1). And I also added these two lines to my /etc/samba/smb.conf file:
client max protocol = SMB3
server max protocol = SMB3
Holy crap, uninstalling SMB 1.0 on my Windows machines just gave me about 30 MB/s bump in speed.
It would sometimes go down to 80 MB/s and with this change it is sustained at about 110 MB/s. Nice change!
Yes, if you want to store a text file with one byte in it, it takes a minimum cluster size space on the disk which can be around 4000 bytes or so depending on how it was formatted.
I'm guessing the Windows size screen is looking at information that Samba isn't reporting back correctly for the 'size on disk' information.
I don't know the answer, but I've always just ignored the size on disk as a garbage number.
When I set it to your settings it gave an error saying:
"You have SSL enabled for the main UI, Do NOT enable it here as well."
I went into 'General Settings' and disabled SSL. That change allowed me to replicate your settings. However I still get the following from the browsers:
192.168.1.4:8081 => Unable to connect.
192.168.1.4/sickbeard => Error 404 Sorry, the page you requested was not found.
I then uninstalled it and reinstalled it and set the settings to exactly what you have listed in your post.
192.168.1.4:8081 => The page isn't redirecting properly.
Rebooted to see if that had any effect:
192.168.1.4:8081 => The page isn't redirecting properly.
I wanted to try out Sickbeard so I installed it and tried to load it in the web client (OMV_IP/sickbeard). I must be doing something wrong, but I'm not quite sure what because it isn't coming up no matter what I try. I always get a Gateway Time-out (nginx) in the web browser.
What I did:
- Installed Sickbeard
- Settings:
- Enable (on)
- Show tab (off)
- SSL (off)
- Proxy Pass (on)
- Repository (default)
- Branch (default - master)
- Second version:Enable (off)
- Clicked on 'Open Web Client' ->Timeout
- Tried to open 192.168.1.4/sickbeard -> Timeout
I ran into the same problem with the ASRock N3150DC-ITX board. My solution was to use UEFI boot. In the BIOS it's under the option disable legacy or some similar description. The OMV installer isn't UEFI capable so I installed Debian 7.9.0 (which is) and then installed OMV on top of it.
I also bought a dummy HDMI connector from Amazon for $15, but ended up not needing it after I enabled UEFI booting.
The console fix sounds good too, wish I had know about that earlier. What is the practical effect of using the console setting? Would it disable the use of a monitor entirely if you were to hook one up?
Nothing relevant is written to the log.
If I interpret this one way, you are getting Samba log statements, but nothing about the failure is showing up? No ideas here.
If I interpret this the other way, you are saying that no Samba log lines are present? If this is the case in the smb.conf there are several log options. Make sure you know which log file it is using (it can be specified). Not seeing the logs should be resolved first to debug the problem.
Edit: Okay, nevermind, ignore my post, you are a posting ninja.
To debug it you'll probably need to turn up the logging level in smb.conf (it is set to 0 by default I believe, 2 should get you started), restart the service (service samba restart), and then look at the system log to see what exactly is going wrong.
I used the same method to install Debian 7.9 for the UEFI support, so you should be okay going that route.
Samba access issues for me is typically because I forgot to setup the Samba/User permissions correctly *or* Windows is caching the wrong user. Here's what I typically do to straighten out Samba access issues:
1) OMV: What permissions 'user' has in OMV under User -> privileges. Make sure they are right and make sure you have the correct user.
2) In Windows it caches/saves the username/password for network access. If it is trying to connect with a user name that doesn't have the correct permissions, this will need to be cleared out. (Substitute in your IP address and username below.)
a) Close any open explorer windows showing the network location.
b) net use \\OPENMEDIAVAULT /delete
c) net use \\OPENMEDIAVAULT * /user:yourusername
Do you have the recycle bin enabled? If so, did you also install the samba-vfs-modules upon which the recycle bin relies?
apt-get install samba-vfs-modules
When I updated to a Samba 4.1x backport I had a similar issue where I could see the folders, but not enter any that had the recycle bin enabled. Enabling logging for Samba showed it couldn't find the vfs modules and resulted in the access issue you are mentioning. So this is one thing for you to check.
Ha! Nailed it. I guess they moved the default location and samba-vfs-modules wasn't installed by default.
I used:
apt-get install samba-vfs-modules
And that fixed it. Bingo!
Edit: Correcting my notes above with the new information.
I was doing some reading up on the vfs objects. Pretty cool in how they intercept the requests and can selectively perform actions.
Anyway, so it should be looking for the shared object files:
Here: /usr/lib/samba/vfs
Not Here: /usr/lib/x86_64-linux-gnu/samba/vfs/recycle.so
I'm not sure where it picked up the extra x86_64-linux-gnu in the path. If I can find where that is specified I could correct it.
The samba backport installed without problem.
Exact steps I used for anyone interested:
Samba Backport:
Reference:
http://backports.debian.org/Instructions/
Add the following line to /etc/apt/sources.list:
deb http://http.debian.net/debian wheezy-backports main
Update the package index:
apt-get update
Install smbclient deb package:
apt-get -t wheezy-backports install samba
# Fixes issue with Recycle below
apt-get install samba-vfs-modulesThere was the question of whether to use a new smb.conf or the existing. In VirtualBox I used both to be able to examine the differences. Upon inspection they were very similar so I used the existing smb.conf file. It works except for if the recycle bin is active it won't allow you to browse into the shared folder and it will give the following error in the syslog file (once the logging level is turned up a little):
Jan 3 18:19:12 OMVTest smbd[5376]: Error loading module '/usr/lib/x86_64-linux-gnu/samba/vfs/recycle.so': /usr/lib/x86_64-linux-gnu/samba/vfs/recycle.so: cannot open shared object file: No such file or directory
Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.213405, 0] ../source3/smbd/vfs.c:184(vfs_init_custom)
Jan 3 18:19:12 OMVTest smbd[5376]: error probing vfs module 'recycle': NT_STATUS_UNSUCCESSFUL
Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.213688, 0] ../source3/smbd/vfs.c:349(smbd_vfs_init)
Jan 3 18:19:12 OMVTest smbd[5376]: smbd_vfs_init: vfs_init_custom failed for recycle
Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.213938, 0] ../source3/smbd/service.c:640(make_connection_snum)
Jan 3 18:19:12 OMVTest smbd[5376]: vfs_init failed for service Movies
Jan 3 18:19:12 OMVTest smbd[5376]: [2016/01/03 18:19:12.214634, 0] ../lib/util/modules.c:48(load_module)So minus the recycle option it seems to be working fine.
the install is a little tricky if you have 3.6 installed
Do you have any tips on what was tricky and how to avoid the issue(s)?
That's not the samba server. I though you wanted to test against windows clients
You are correct. Samba server is what I'm after. I found that on the web and didn't realize it was talking about a Samba Client. If I substitute in the equivalent name for the samba server package instead of 'smbclient', is that how you'd recommend getting the backport?
ZitatYou can upgrade to the wheezy backport kernel if you have not done so in OMV Extras with a button in the Web GUI.
Yep, nice feature!
Good advice, thanks tekkb and subzero!
My general plan:
1) Try the newest driver. Keep the kernel & samba default.
2) Try the samba 4.1 backport.
3) Try the kernel backport (and redo the driver for the new kernel, right?)
4) Buy a $25 Intel NIC
Regarding the Samba Backport. Do you suggest anything different than these instructions?
Add the following line to /etc/apt/sources.list:
deb http://ftp.debian.org/debian/ wheezy-backports main
Update the package index:
# apt-get update
Install smbclient deb package:
# apt-get install smbclientFor the kernel backport I'd use the OMV Extras tab automation.
I did some reading and there have been various posts about how the kernel's use of the r8169 drivers can cause issues for r8168/8111 hardware.
Some of the failure descriptions are spot-on for what I am experiencing:
https://bbs.archlinux.org/viewtopic.php?id=101836
Are there any cautions about downloading/applying the latest r8168/8111 drivers from RealTek's website?
I still wonder why I only see this with Samba. I transferred half a TB with NFS and it was rock solid. It was only with Samba that I get the random network lockup. I suppose it could be the way Samba is interacting with the driver that NFS isn't. So potentially updating Samba might be a viable path as well.