If you insist on not giving each user an account (recommended) and instead of fighting Windows, you should create a user on OMV and give that user access. Then put that user in the credential manager on each system.
Read this - https://wiki.omv-extras.org/doku.php?id=omv7:new_user_guide
Google for windows credential manager.
However, I looked at the guide and I didn't see any mentioned about how to do what you want. Can you point me to the part in the guide that tells me how to do it.
I posted the wrong link - https://wiki.omv-extras.org/do…omv7:nas_permissions_omv7 It even has a link for the credential manager stuff at the end. Don't be afraid to read other wikis on the omv-extras wiki.
I also have been hit by this issue on my Windows computers upgraded to 24H2. When trying to open shares on OMV 7.x, I got authentication failed error because NTLM is disabled. My laptop which stays on 23H2 doesn't experience this error.
My OMV has always been running Samba with "server min protocol = SMB2" and "server signing = mandatory" since maybe OMV 5.x without any problems. It appears that this Windows update 24H2 indeed changed the protocol negotiation and broke the connections to my Samba shares.
Anyway, it does seem Windows 24H2 is the culprit, not OMV. But, if there is a setting on the OMV which makes the Samba shares work again, I will be very happy.
My OMV has always been running Samba with "server min protocol = SMB2" and "server signing = mandatory" since maybe OMV 5.x without any problems.
Go with no statements, in Services, SMB, Settings, Extra Options, and see what happens with your LAN clients. (Check all your clients, to include SMART phones that connect to your shares.)
This would be the ideal solution in that, as Windows pushes out unannounced security updates, the open source side may be able to compensate for the changes (on the fly) with SMB package updates.
I do have a Win11 Laptop that's connects to my SMB shares, but it hasn't been updated to 24H2.
I'm updating the laptop to 24H2. We'll see what happens.
win11 enterprise 24h2 is able to access a samba share on omv 7.7. I had smb2 set to the minimum protocol in the Advanced Settings section of the Settings tab. If you created the user before enabling samba, you might need to set your user's password in the Users tab again (can be same password I think) or you can use this command to set the samba password for the user (yes, samba has its own password database):
sudo smbpasswd -a aaron
you might need to set your user's password in the Users tab again (can be same password I think) or you can use this command to set the samba password for the user (yes, samba has its own password database):
sudo smbpasswd -a aaron
I thought this was set, when a user is created in OMV? (Or, if not set, does it default to the Shared Folder's permissions?)
_______________________________________________________________________
kochin
I updated the laptop to 24H2 with no consequence to SMB share access.
In SMB global (Under, Services, SMB/CIF, Settings. I have nothing in extra options) Other than changing the workgroup name to what I use, this screen is at defaults.
In each of my SMB individual share settings (Under Services, SMB/CIFS, Shares) I have server max protocol = SMB3 (Note that this statement is max, not min, but this statement isn't really necessary.
However, in my case, I have all of my LAN's usernames and their windows passwords entered in OMV. Info on how to set this up is available here -> NAS Permissions. Try this with the username and password, used to login to the laptop that's not working.
I thought this was set, when a user is created in OMV? (Or, if not set, does it default to the Shared Folder's permissions?)
smbpasswd only changes the smb password if samba is running. So, if you create or edit a user before samba is running or even if it is stopped, then the user's samba password will potentially be wrong.
It isn't really a permissions thing. The user has permissions. If the user's password that Windows is sending to the samba server is different than what the samba server has in its database, the user will not have access to anything other than maybe shares that have guest permissions.
Hi,
I just wanted to bounce on this message, as it gave me the explanation for what I thought was a bug.
I recently installed OMV on a raspberry pi 5 following the instructions at https://wiki.omv-extras.org/do…i_os_updates_and_upgrades .
I struggled for quite a while, not understanding why samba authentication was failing. Until I created a new user and it worked fine. As it happens, this method of installation adds OMV onto an existing raspberry pi OS installation, so the default user is picked up by OMV and can get folders shared without any additional user setup in the UI... BUT technically, it IS created before Samba is running; it's even created before OMV is even installed. So that might explain why I had to run `smbpasswd -a username` for samba to start working for that user.
I would suggest one of 2 improvements:
- make it so that the default user gets a smbpasswd configured automatically during this installation procedure
- if not possible for technical reasons, document this clearly, at least in the page linked above; ideally also inside the UI itself, to let people know "this user was created before OMV was installed; please reset the password if you need this user to have access to SMB shares" - something along those lines.
Hope that makes sense, sorry if not!
P.
- if not possible for technical reasons, document this clearly, at least in the page linked above; ideally also inside the UI itself, to let people know "this user was created before OMV was installed; please reset the password if you need this user to have access to SMB shares" - something along those lines.
If you create a user before OMV, then you should have to run smbpasswd (or change the password in the OMV web interface after samba is enabled). The guide isn't telling you to create a user before installing OMV. We can't write something for everything a user might do before installing OMV. That is why we tell people to install OMV first.
First off, it seems I'm going to have to put a note in the guide, not to deviate from the guide.
_______________________________________________________
With the above noted and with emphasis on #2 below, nowhere in the guide does it say to:
1. Flash an SD-card with Rasp. PI OS.
(Then)
2. Install users of your choice, configure WiFI, add additional non-OMV packages, etc., etc.
3. Install OMV.
Where #2 is concerned, it is IMPOSSIBLE to to predict or anticipate what users many do, at any point, before, during, or after:
(1) Flash the card
(2) Install OMV.
There are an infinite number of ways to break an install.
Until I created a new user and it worked fine. As it happens, this method of installation adds OMV onto an existing raspberry pi OS installation, so the default user is picked up by OMV and can get folders shared without any additional user setup in the UI... BUT technically, it IS created before Samba is running; it's even created before OMV is even installed. So that might explain why I had to run `smbpasswd -a username` for samba to start working for that user.
Take a look -> here. It's relatively easy to provide samba access to existing Windows users on the LAN.
Of course, if it's not obvious, the info in this document applies AFTER OMV is installed AND you'll need to install users as the document illustrates - in the GUI.
At the end of the doc, under Permission Notes, using an externally linked doc:
You can set up a "universal access" user VIA the Windows Credential manager.
Hi !
Sorry if I explained incorrectly. I'll try to reply to both.
The guide isn't telling you to create a user before installing OMV. We can't write something for everything a user might do before installing OMV. That is why we tell people to install OMV first.
Indeed, but I did not create a user before installing OMV. When flashing raspberry pi OS using the official raspberry pi flashing tool, a user is created by default, with sudo privileges; root doesn't even get a password set up and cannot log in. So, that user is pretty much the only way to use the Pi, and OMV gets installed by that user, using sudo (the instructions correctly reflect this). Therefore there's no extra step taken. In fact, I'm fairly confident that I literally flashed the OS, logged in via SSH, and immediately updated the system with apt, called the preinstall, rebooted, and called the main install.
That single user that is set up by the raspberry flashing process is then automatically visible in the list of users in OMV, without any action required. BUT it's not obvious to new users like me that for this particular user, I'll need to run smbpasswd manually because that's the user through which I followed the instructions.
1. Flash an SD-card with Rasp. PI OS.
(Then)
2. Install users of your choice, configure WiFI, add additional non-OMV packages, etc., etc.
3. Install OMV.Where #2 is concerned, it is IMPOSSIBLE to to predict or anticipate what users many do, at any point, before, during, or after:
As per above, step 2 for me was basically nothing. I flashed the os, plugged the device in (incl. ethernet cable, so no wifi setup even), logged in via ssh and moved on with step 3.
It's relatively easy to provide samba access to existing Windows users on the LAN.
Fixing the issue was trivial once it was clear what was happening. However I did struggle in understanding it was happening, from the lack of warning in those raspberry-specific instructions, and the lack of particular warnings in the UI about this user being "somewhat different" because not created through the UI, but by the raspberry install + OMV install together.
Hope that clarifies!
Indeed, but I did not create a user before installing OMV. When flashing raspberry pi OS using the official raspberry pi flashing tool, a user is created by default, with sudo privileges; root doesn't even get a password set up and cannot log in. So, that user is pretty much the only way to use the Pi, and OMV gets installed by that user, using sudo (the instructions correctly reflect this). Therefore there's no extra step taken. In fact, I'm fairly confident that I literally flashed the OS, logged in via SSH, and immediately updated the system with apt, called the preinstall, rebooted, and called the main install.
That single user that is set up by the raspberry flashing process is then automatically visible in the list of users in OMV, without any action required. BUT it's not obvious to new users like me that for this particular user, I'll need to run smbpasswd manually because that's the user through which I followed the instructions.
using the pi user for omv install andapt things is fine. I guess the guide should say (and maybe it does - haven't read it lately) "After installing OMV, don't use the pi user for anything at all especially samba. create new users" When I wrote the install script, I wanted to delete the pi user but too many people complained. People should not use the pi user after omv install though.
I guess the guide should say (and maybe it does - haven't read it lately) "After installing OMV, don't use the pi user for anything at all especially samba. create new users" When I wrote the install script, I wanted to delete the pi user but too many people complained. People should not use the pi user after omv install though.
Thanks for your reply, I see where you're coming from. It doesn't help that the Raspberry flashing tool offers the option to customise that default user, as part of the standard install, so in my system it's not `pi` but the name of the friend I prepared the install for. Which made it all the more tempting to use as a samba user!
I don't think the current docs have a sentence like the one you wrote there - maybe I missed it, but it doesn't ring a bell. It would be useful to add, somewhere close to the installation steps so it catches everyone's attention.
OK,,, I put a note in the Imager section, that the user created by the Imager (whatever name the installer may chose) and the Rasp-PI OS default user pi will not have access or OMV "stuff" OR they will have to be entered into the user section of the GUI.
In the hope of preventing other install issues, I also added a "Do not deviate" FOREWORD.
Don’t have an account yet? Register yourself now and be a part of our community!
