Since evidently our support is lacking (I don't use samba at all at home), I updated one of my RPi4, created a new sharedfolder, enabled samba, created a samba share from the new shared folder, create a new user, and gave the new user privilege to the new shared folder. I am able to access this shared folder with the new user from Linux (xubuntu 22.04 amd64 and Raspberry Pi OS with desktop on RPi400) and Win10.
Unable to access CIFS/SMB shares from Linux - works in Windows
-
- OMV 6.x
- gelöst
- Sol-Illadan
-
-
Since evidently our support is lacking (I don't use samba at all at home), I updated one of my RPi4, created a new sharedfolder, enabled samba, created a samba share from the new shared folder, create a new user, and gave the new user privilege to the new shared folder. I am able to access this shared folder with the new user from Linux (xubuntu 22.04 amd64 and Raspberry Pi OS with desktop on RPi400) and Win10.
I will try to do a fresh install as well. Its stuck so long, i am afraid that my wife & family will revoke our homelab privileges as its "not providing results", ryecoaaron, have you configured any settings in samba config extra that might be a factor ? I have simply kept the protocol min as SMB2 & max as SMB3.
Alles anzeigenMaybe because those who use arm devices don't use SAMBA and don't have nothing to add?,
Honestly, after mounting the drives via NFS on my Windows, I will never go back to SAMBA.
Only thing is, I have no Linux rig to test it.
Unless you count LibreElec/Kodi (with ZeroConf) which, as a matter of fact also plugs to the NFS share without problems.
And, after skeeming through the Thread and reading a lot of things I don't understand, I see now that my input isn't helping either, sorry.
As for the OPs situation Sol-Illadan , if you want to try NFS on Windows, I can give some pointers.
Maybe it will sort your Linux && Windows connections.
Soma, I have total linux experience of 2.5 years & have barely expanded my learning due to college & other factors at home. Even my brother had to have his systems dismantled as Its cluttering up the house & as per the words of our mother - "why do you need all this chetta (trash in mother tongue) - you do not need them to get a job.".
We both would like to expand to NFS , just that we had never before got exposed to nor used it. My only concern was that from what I managed to read, NFS doesn't have user based auth, so we were concerned as we have a couple of systems which is shared among all family members & would not be possible to restrict some shared folders to others.
I & bro will definitely expand our knowledge base & will see if we could rig up the shares using NFS as well.
-
have you configured any settings in samba config extra that might be a factor ?
Definitely not. Since I don't use samba, I left everything default.
-
We both would like to expand to NFS , just that we had never before got exposed to nor used it.
I also never used it but after getting so tired from all the hiccups with SAMBA, I just googled it and tried it.
It works for my use case.
My only concern was that from what I managed to read, NFS doesn't have user based auth
If by this, you mean to have a auth box coming up whenever you try to log into the share, than I believe you're right (not 100% sure of this since I haven't digged into it).
But if you want to mount the share as a drive on Windows Explorer, then it's possible to make it only available to the user you want with a hack on the Windows Registry.
The mounted share will be logged with the UID && GID that you set on it with the permissions that are assigned to that specific share.
This will restrict the share to a specific user(s).
» New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value <unix_export_owner_uid> -PropertyType "DWord"
» New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value <unix_export_owner_gid> -PropertyType "DWord"
I can say that it's a bit of work, especially if you want to have a lot of different permissions on the same share but, if you only have a few users with the same amount of different permissions, it's a one time job on each persons PC.
Maybe this is an overly simplified perspective of how to use NFS shares but it's the way I found it to work for me.
On the other hand, if you want to have different access privileges to different people on the same folder, you can also go with Nextcloud.
For example, you have a folder with photos that you want userA to have RW access and userB with RO.
You have the folder mounted locally on Nextcloud and you allow userA to mount it RW but userB mount RO.
Both users have a WebGUI access to a folder but with the permissions setted by you.
And the funny thing is, you don't even mess with Linux permissions of the folder other than the need to be owned by the UID that launches the Nextcloud service.
Sorry for deviating from the topic. Just picturing different approaches to what you want to do and with different alternatives (mainly to SAMBA)
-
I have been keeping up with this thread and til now have have stayed out, why? because it just makes no sense, I've personally never had an issue connecting to smb from windows or linux and as ryecoaaron has proved it is that simple. There is no need for extra options in smb on omv.
The question is how are the linux clients set up, we know Armbian and DietPi and that's it, Xubuntu is a full blown Linux desktop, whereas the likes of DietPi is not.
I use DietPi for Pi-Hole with unbound it is not like Xubuntu, Mint or any other Linux desktop distro, DietPi is distributed as a lightweight SBC install, in essence whilst it's menu driven it's cli based. I see DietPi can be installed on a VM, as I have virtualbox installed on my W10 desktop I could test that out.
NFS has been suggested to use between OMV and Linux clients, makes sense, and there was a discussion on the forum (can't find it) as to whether it was possible to point a shared folder to NFS and SMB where there was mixed client network.
Something else I used to do years ago to get SMB to 'pick up' SMB shares was to install cifs-utils, don't know if that's even needed these days
-
DietPi works in a vm and mounted one of my omv smb shares, albeit crude and would require some tweaking ->
So what did I do, installed the dietpi image logged in which then runs the usual update, then using the software manager, installed lxde, samba client, which actually installs cifs-utils
and then nfs client, I also had to install xrdp cos windows wouldn't connect.Then the DietPi-Drive Manager did work from the desktop menu
so ran it from the cli, this requires a username and password to make the connection, which I have on OMV anyway, then proceeded to follow the menu instruction left everything at default hence the share showing as /mnt/samba. Oh it connects using samba v3.1.1So DietPi will connect to OMV's smb shares without any extra options, I'd call that a result
As this is a VM I could test accessibility of setting up an OMV share and pointing to SMB and NFS, but that would have to wait
As Sir Bruce Forsyth used to say 'Didn't he do well'
-
I've personally never had an issue connecting to smb from windows or linux and as ryecoaaron has proved it is that simple.
I haven't had a problem either. What I suspect may be happening is permissions conflicts.
In OMV6, the permissions window has been organized with ACL's at the top in a large, line by line, format. This almost begs users to start clicking ACL boxes. Native Linux permissions (Owner, Group, Others) are at the bottom of the page, where they're likely ignored by users who are familiar with Windows. *Note that Windows users are the majority.*
With native Linux permissions being applied by default, in the Shared Folder creation process, clicking ACL boxes is going to cause unexpected problems. Throw Samba permissions into the mix and there's a lot of pit falls for a new user to navigate.
In my opinion, within Shared Folders, native Linux permissions and ACL's should have their own separate tabs. I'd think about putting a caution note on the ACL page that warns of conflicts if ACL's and native permissions are used at the same time. I'd even go so far as to have a check box that enables GUI support of ACL's, with a cautionary dialog box, before the ACL tab appears.
Further I'd set the defaults of Shared Folders to "Everyone" read/write and Samba to "Guests Allowed". With those settings, users who want to tighten up security could inquire,, but all user's Samba shares would work by default. -
What I suspect may be happening is permissions conflicts
That was one of my thoughts as well, I've just tested directing a shared folder to nfs and smb, doesn't appear to be an issue.
Whilst DietPi is not the most intuitive I did finally manage to get both nfs and smb working (which were pointing to the same share on omv) mounted on lxde under DietPi.
So the solution at least for DietPi is to create the share on omv, enable in smb and nfs, point DietPi to nfs and allow Window to use smb
Jobs a good 'un
-
So the solution at least for DietPi is to create the share on omv, enable in smb and nfs, point DietPi to nfs and allow Window to use smb
I've never had a problem connecting from Linux to SMB. On the other hand, I eliminate problems before they start.
The first thing I test, when looking at a Linux Distro, is SMB client connectivity to an OMV SMB share with wide open permissions. If the Linux SMB Client won't do that, I look for something else.
On the other hand, your approach of creating an NFS share and an SMB share, for the same shared folder, seems to be the best way to go. -
I've never had a problem connecting from Linux to SMB. On the other hand, I eliminate problems before they start.
The first thing I test, when looking at a Linux Distro, is SMB client connectivity to an OMV SMB share with wide open permissions. If the Linux SMB Client won't do that, I look for something else.
On the other hand, your approach of creating an NFS share and an SMB share, for the same shared folder, seems to be the best way to go.I've honestly yet to find a mainstream Linux distro that can't connect to an SMB share, usually out of the box (Debian, *buntu, Mint, Fedora, OpenSuse.. probably more I'm missing), ... a few might need you to install a package or two but it's generally painless. To be truthful, with limited experience I've had a bigger headache explaining SMB to Windows 11 users than I ever have with Linux
geaves mentioned pointing SMB and NFS at the same share. I know it's not usually recommended (apparently it can cause issues with permissions) but my Shield for some reason, despite NFS being supported, just will not connect to NFS. I can connect to NFS on all my other devices without issue. So I have an SMB share set up pointing to my Media directory so Kodi can use it. My other devices access the same share via NFS... and it's never caused me an issue in about 6yrs. That said, Kodi really doesn't do anything but read the directory.. so the permissions it needs are pretty limited.
-
Sol-Illadan
Hat das Label gelöst hinzugefügt. -
I know it's not usually recommended (apparently it can cause issues with permissions)
TBH I was wondering if that might be an issue, but I also thought if one didn't mess around with acl's (which is what I did in trying this out) in other words keep it simple for a home environment it just might be usable.
Do you not use Emby as your media server? I use the Kodi companion plugin on Emby and the Kodi next gen on Kodi itself that way I don't have to set up anything in Kodi.
On the other hand, your approach of creating an NFS share and an SMB share, for the same shared folder, seems to be the best way to go
I did it just as a test would be it a solution in the long term, possibly, but as KM0201 has suggested permissions could be an issue, but for home use and not using acl's it might be a solution.
-
TBH I was wondering if that might be an issue, but I also thought if one didn't mess around with acl's (which is what I did in trying this out) in other words keep it simple for a home environment it just might be usable.
Do you not use Emby as your media server? I use the Kodi companion plugin on Emby and the Kodi next gen on Kodi itself that way I don't have to set up anything in Kodi.
I did it just as a test would be it a solution in the long term, possibly, but as KM0201 has suggested permissions could be an issue, but for home use and not using acl's it might be a solution.
I use Kodi at Home. I honestly have always liked it's interface over Plex, Emby, etc. I've thought about using the Emby plugin, but I've just used Kodi so long I just really like it.
Emby is only to stream when I'm not at home, or occasionally let someone download something from me... You know like the only person on the planet that hasn't seen Forest Gump
-
Sol-Illadan So it was a basic permissions error. After you’d said you had used the same account/folder perms/privileges on both your OMV5 and OMV6 installs I went down the wrong rabbit hole instead of sticking with basic permissions fault finding, delaying a solution to your problem.
Here’s an example of how things can go wrong. In this case it’s a raspberry pi trying to connect to a OMV share:
Code
Alles anzeigenroot@192.168.0.205's password: Welcome to Arch Linux ARM Website: http://archlinuxarm.org Forum: http://archlinuxarm.org/forum IRC: #archlinux-arm on irc.Freenode.net Last login: Sat Nov 26 13:08:02 2022 from 192.168.0.201 [root@soa-rpi ~]# mount -t cifs -o user=chris //192.168.0.75/armsample /mnt Password for chris@//192.168.0.75/armsample: mount error(95): Operation not supported Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) [root@soa-rpi ~]# mount -t cifs -o user=chris,vers=3 //192.168.0.75/armsample /mnt Password for chris@//192.168.0.75/armsample: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) [root@soa-rpi ~]# mount -t cifs -o user=chris,vers=2.1 //192.168.0.75/armsample /mnt Password for chris@//192.168.0.75/armsample: [root@soa-rpi ~]# cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 2.00 Features : half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 Hardware : BCM2708 Revision : 0010 Serial : 0000000071c5961e [root@soa-rpi ~]#It only connects using SMB vers 2.1
But I’m curious how/why linux clients connecting to OMV5 used HMAC-SHA256 signing which I associate with SMB2 (see #9 above ). AFAIU neither rpi3 or rpi4 have crypto extensions enabled in hardware, but I don’t know about odriod hardware. Perhaps there are odriod owners who might explain that and can say what crypto kernel modules get loaded on boot that could led to
HMAC-SHA256to be used for SMB signing.I personally would be very wary of sharing the same data with via both NFS and SMB at the same time. If at least one or the other is read only you might be OK, otherwise expect problems. IIRC synology NAS allow this but take care of the necessary kernel locking in the background. But I wonder about Windows software that makes use of the archive file attribute, what would happen if some of your shared data had been written via NFS and was then accessed in Windows?
KM0201 You must be talking about desktop distros where the file managers use helper programs in the background to handle SMB connections. On linux servers, or for fstab, autofs or systemd mounts you need kernel mounts and cifs-utils or equiv package to be installed.
Avahi is a core part of OMV but not necessarily on a given linux desktop distro/DE. For those that have it, icons might appear in file managers for NFS shares. These don’t always work smoothly, or at all, as the linux software doesn’t necessarily correctly distinguish between NFSv4 and NFSv3 exports. e.g.:
For mounting NFS shares outside of any desktop file manger you will need nfs-common or equiv package to be
installed.In the home environment with a mix of windows and linux clients, SMB shares still seems like a reasonable choice to me.
-
KM0201 You must be talking about desktop distros where the file managers use helper programs in the background to handle SMB connections.
In the home environment with a mix of windows and linux clients, SMB shares still seems like a reasonable choice to me.
I never suggested I wasn't, or that it wasn't (I guess I just assumed we were talking desktop clients here).
I've had issues with Linux and SMB a little bit in the past.. nothing deal breaking just here and there.
NFS has always caused very few issues for me over the years
If I had more Windows machines here I'd be more concerned with it. The love of my life is Mactarded. She rarely uses the Network shares.. she uses Calibre a lot for reading so I have a calibre server running in docker that she can access.... but beyond that... she wouldn't know the difference.
-
I never suggested I wasn't, or that it wasn't (I guess I just assumed we were talking desktop clients here)
This was the whole problem with this thread was the first post nowhere is there any information or than DietPi and Armbian and that doesn't come out until #7
-
This was the whole problem with this thread was the first post nowhere is there any information or than DietPi and Armbian and that doesn't come out until #7
Meh, who needs details in a forum like this? Sling enough crap at the wall and something will eventually stick.
-
The love of my life is Mactarded.
-
I'm assuming that's what the preacher meant when he said "for better for worse. In sickness and in health"
-
I'm assuming that's what the preacher meant when he said "for better for worse. In sickness and in health"
I'm sure the "catch all" includes "Mactardedness".
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!