Posts by Borbio

Bump.

I have NFS shares from OMV mounted on a mac mini client and everything works fine except...

If I open a mac Finder window on one of the shared directories, about 15 minutes later it mysteriously resets to the top-level view of all available shares.

So, I have to keep clicking back to see the directory that I wanted to leave open.

Any ideas about the cause of this? How can I troubleshoot and resolve this issue?

TIA !

P.S. FWIW I also have a SMB share running on OMV, but pointed at a different volume, and it doesn't reset like this.

P.P.S. My configuration, exports, and fstab for mounting the shares:

macOS 15.5 running on Apple silicon.
OMV 7.7.16-1 (Sandworm) running on Linux 6.12.38+deb12-amd64

omv:~$ cat /etc/exports

/export/omv-04 10.0.1.0/24(fsid=3dc3cc37-cd13-4281-af46-988737870b64,rw,rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=1000,anongid=100)

/export/omv-03 10.0.1.0/24(fsid=9da69a3b-c075-417e-a3da-bca751596094,rw,rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=1000,anongid=100)

/export/omv-01 10.0.1.0/24(fsid=c9aad037-fed1-4073-b9b9-51ce38c7255f,rw,rw,sync,insecure,nohide,no_subtree_check,all_squash,anongid=100,anonuid=1000)

/export/omv-02 10.0.1.0/24(fsid=6312d12c-303d-4526-a3d2-e25f67e6c6f7,rw,rw,sync,insecure,nohide,no_subtree_check,all_squash,anongid=100,anonuid=1000)

/export 10.0.1.0/24(ro,fsid=0,root_squash,subtree_check)

----

Mac-mini ~ % cat /etc/fstab

omv:/omv-01 /Users/myUsername/omv/omv-01 nfs nfsvers=4,rw,resvport,nfc,proto=tcp,port=2049 0 0

omv:/omv-02 /Users/myUsername/omv/omv-02 nfs nfsvers=4,rw,resvport,nfc,proto=tcp,port=2049 0 0

omv:/omv-03 /Users/myUsername/omv/omv-03 nfs nfsvers=4,rw,resvport,nfc,proto=tcp,port=2049 0 0

omv:/omv-04 /Users/myUsername/omv/omv-04 nfs nfsvers=4,rw,resvport,nfc,proto=tcp,port=2049 0 0

Thanks.

Quote from chente

There are ways to automate a CA certificate; search the forum; there are threads that explain how to do this.

I tried that. The only search result for “CA certificate” is this post. There are posts about certificates and docker but I'm not using that.

Any suggestions?

Also, on the Workbench tab, I had SSL/TLS enabled, picked my new certificate, and then enabled Force SSL/TLS, and when I applied the changes, the browser immediately reset and when I tried to refresh the page, I got the "The Connection is Not Private" error again.

How to proceed? I really want to STOP these annoying warnings once and for all.

Thanks. How do I create a certificate and switch to HTTPS? What are the exact steps?

FWIW, I am getting the same error from webmin, running on the same server box running omv.

This is happening repeatedly and I REALLY want to shut it off, once and for all. I don't want to see any more of this for OMV or webmin.

This sort of constant nagging about security on my own LAN is just annoying AF.

EDIT: Looking through the OMV control UI, I found System > Certificates > SSL, and there is a "referenced" certificate that has expired.

(1) I don't find anything about choosing HTTPS vs. HTTP. I thought(?) this was just the default?

(2) I can create a new certificate, though apparently it is self-signed, without root CA — is this going to work for macOS?

(3) Also, why can't I delete the expired certificate? Is this a bug in OMV?

I looked at the OMV wiki page about this, but there are no details to address any of these questions.

How to proceed?

Every time I try to connect to my OMV server using macOS Safari (running Sequoia 15.5), I get this error:

Quote

This Connection Is Not Private

This website may be impersonating “omv” to steal your personal or financial information. You should close this page.

I know it's some sort of certificate issue and I have searched for a fix, but nothing turns up that makes sense to me.

How can I get rid of this error for good?

Thanks for your message.

I tried that tho it's certainly possible I didn't configure it correctly.

Finally, I transitioned all of my OMV media shares to NFS.

It was also complicated to set up, but finally I have it working and there are no issues with filenames.

Quote from Soma

On the client, use showmount -e OMV_IP

Yes, I'm trying showmount -e 10.0.1.25 — and getting the error described above.

Adding: I can mount a share from the mac client, but only NFSv3, and then there are problems.

For example, given two directories on the NFS share — Desert and Désert — I can only access files inside the first one. Basically, any accented characters in the directory names cause an error when I try to open any files within that directory. I can see the files inside Désert, but I cannot access them.

I guess this is happening because NFSv3 lacks proper support for Unicode, but in any case it's a showstopper.

I assume I need NFSv4 for proper Unicode, but I am unable to get mount to work, e.g. trying both mount and sudo mount:

$ mount -t nfs -o vers=4,resvport omv:/export/omv-02 /Users/me/omv/omv-02
mount_nfs: can't mount /export/omv-02 from omv onto /Users/me/omv/omv-02: Operation not permitted
mount: /Users/me/omv/omv-02 failed with 1

$ sudo mount -t nfs -o vers=4,resvport omv:/export/omv-02 /Users/me/omv/omv-02
mount_nfs: can't mount /export/omv-02 from omv onto /Users/me/omv/omv-02: No such file or directory
mount: /Users/me/omv/omv-02 failed with 2

I have searched on the Internet but haven't found any clear explanation or fix for these errors.

How to proceed ?

EDIT: I may finally have a solution !!

There were several issues, which I've resolved using the following mount command on the macOS side:

mount -t nfs -o vers=4,resvport,nfc,proto=tcp,port=2049 omv:/omv-02 ~/omv/omv-02

Notes:

(1) When specifying vers=4 it seems you need to also include resvport.

(2) In order to get Unicode working, you need to include nfc, which will convert file names to Unicode Normalization Form C (NFC).
(3) When specifying the name of the share on the OMV server, it should be omv:/omv-02 for NFSv4, not omv:/export/omv-02 as it was for NFSv3.

On the OMV side, the export definition looks like this:

/export/omv-02 10.0.1.0/24(fsid=6312d12c-303d-4526-a3d2-e25f67e6c6f7,rw,sync,insecure,no_subtree_check,all_squash,anongid=100,anonuid=1000)

Background Discussions

https://superuser.com/questions/250926/wont-read-unicode-characters-over-nfs-mount#:~:text=1%20Answer,on%20Linux%20and%20OS%20X

NFSv4Howto - Community Help Wiki

https://care.qumulo.com/s/arti…tions-for-macOS-and-Linux?

Thanks. Yes, that's more what I would expect.

(1) I haven't changed anything directly in config files — only through the OMV GUI.

(2) AFAIK, there is no firewall running. Just to double check, I tried installing ufw and checking status:

$ sudo ufw status
Status: inactive

Running the same commands you tried, here's what I get:

Not sure why I need to use sudo to run showmount. I tried that on the client side, but I still get the same error:

showmount: Cannot retrieve info from host: omv: RPC failed:: RPC: Program/version mismatch; low version = 3, high version = 3

One other thing I noticed about rpcbind, idk if it matters but there's a warning about permissions on journal files:

Well, I thought I had NFS sorted, but in fact it's still broken.

I have spent days pulling my hair out over this and am making little progress.

Tbh, I see a number of other unanswered questions about NFS here, and am now wondering if(?) I need to begin looking at a different NAS.

I can get a NFS share mounted, but there are then other problems. I believe something basic is wrong with the OMV server config, because showmount always fails:

showmount: Cannot retrieve info from host: omv: RPC failed:: RPC: Program/version mismatch; low version = 3, high version = 3

I've never been able the get showmount to list shares on OMV, and no idea what this error actually means. I have NFSv3 and NFSv4 enabled on OMV.

I've tried taking this up on the Debian forum but they consider OMV to be some kind of derivation and don't want to discuss it.

How can I fix this?

EDIT: I finally got it working, at least for NFSv3.

My notes can be found here: https://forums.debian.net/viewtopic.php?p=825365#p825365

I'm getting odd errors on the macOS client side, e.g.:

$ showmount -a  10.0.1.25
showmount: Cannot retrieve info from host: 10.0.1.25: RPC failed:: RPC: Program/version mismatch; low version = 3, high version = 3

On my OMV server, the /etc/exports file looks like this:

/export/omv-2025-01 10.0.1.0/24(fsid=5c62a167-aba5-4115-b68c-e5ed8d459d34,rw,subtree_check,insecure,allow_nonroot)
/export 10.0.1.0/24(ro,fsid=0,root_squash,subtree_check)

I'm stuck. How to proceed?

P.S. FWIW, I'm using OMV 7.7.11-1 (Sandworm) on Debian 12.11, and trying to connect from macOS Sequoia 15.4.1.

Thanks for sharing all of this.

I think I have no choice but to throw in the towel on SMB and use NFS.

Thanks. I tried enabling vfs_fruit, but it doesn't seem to behave any different than mangled names = no.

More specifically, adding this to the SMB settings for OMV:

fruit:aapl = yes

ea support = yes

vfs objects = catia fruit streams_xattr

fruit:resource = file

fruit:encoding = native

Restarting the SMB server via OMV, and rebooting the mac client. No change.

FWIW, I'm not asking for full macOS filename support (see above), only Linux filename support on a mac share (the OMV instance is running on a Debian box). SMB is running on a Linux machine, but it is scrambling legal Linux filenames into something weird.

That is, unless I enable mangled names = no or add these options for vfs_fruit, the Linux filenames with trailing dots — a legal filename on Linux and macOS — won't be displayed correctly for the Linux share. And then, even when mangled names = no, there is still some weird mangling happening. I.e., a trailing . is fine on both Linux and macOS, but SMB is nevertheless doing something strange to the filename, mapping . to 0xEF 0x80. AFAIK, both macOS and Linux use UTF-8 internally, and a filename with a trailing dot is legal on both of them.

Why does this matter?

Let's say you have a media or music player app and it organizes albums in directories under the name of the band. The player app uses OMV to store the music. So, it expects a directory R.E.M. for the band named R.E.M. This is a legal filename on both Linux and macOS, but SMB scrambles it, as described above, such that one name is presented to the mac and another appears on the Linux volume.

Needless to say, this is a problem for the music player app, which then fails to find a band named R.E.M0xEF 0x80.

EDIT: Looks like I spoke too soon about "no change". Enabling vfs_fruit has changed the creation and modification dates of every folder on my SMB shares, and they are now mostly all the same. I have no idea what the logic is behind this but it's undesirable. So, I've disabled vfs_fruit.

Quote from eightbit

My experience with samba is, the problem often lies in not fully compatible implementations on client- and server-side.

That could be the issue with macOS, tho the question remains: is there a work-around?

Some further data points:

(1) If I add mangled names = no as a SMB config option and then reboot, now SMB appears to work from macOS, showing me expected directory names instead of mangled ones, tho if I create a folder named Test. on the SMB share, it looks correct from the mac side, but on the Linux SMB server the file is named Test, with unprintable 0xEF 0x80 at the end.

Having differently-encoded filenames on macOS and Linux, and unprintable filenames on the Linux side — this is a deal-breaker for me.

(2) I also tried dos charset = UTF-8 as a SMB config option, but then testparm -v | grep "dos charset" reports an error:

ERROR: invalid DOS charset: 'dos charset' must not be UTF8, using (default value) CP850 instead.

It seems that CP850 was later replaced by Windows-1252, then UCS-2, and finally UTF-8.

So, my only guess the mangled filenames are being sent in the legacy CP850, and then it is somehow the client's responsibility to ask for its non-legacy representation, but the macOS SMB client isn't doing this.

Quote from votdev

Maybe you should ask the question if the problem isn't MacOS Sequoia. I have no problems with Samba from my Linux and Windows clients.

You're right, it should work out-of-the-box for most scenarios. But this cannot happen if the community does not actively participate in the discovery and elimination of bugs. I don't have a Mac, so I can't do anything in that direction to fix problems.

Many ppl do say the macOS client has problems. All the discussions I've seen, though, suggest the work-around happens on the SMB side, because it's sending mangled DOS filenames to the client.

Point taken about community participation. If I learn anything I will definitely share it here.

Quote from votdev

Knowing how they solved the issue should help to solve the issue for OMV.

Yes, I wish I knew. From reading several dozen threads on this (e.g., above), I find some people say that adding "mangled names = no" as a SMB config option worked for them, but some others say that all it does it show the directory names properly, and the files inside the directories don't appear.

I tried this on OMV and my experience was the latter. So, I haven't found any solution that works with OMV.

There are a dozens of config settings for SMB. One of the main reasons I started with OMV in the first place was so that I wouldn't have to d*ck around with them.

If I have to get into trial-and-error fiddling with SMB config settings... what's the point of using OMV?

I might as well just go back to using SMB with Webmin like before, except that was a nasty experience — performance was bad, connections were janky, etc. — and thus my original question:

Should I bail on SMB, because it's always going to hobbled with DOS-era limitations, or is there a solution?

Thanks for your message. I just looked again, and I don't see any such setting on the SMB share config page. What is it called, specifically?

W.r.t. the wild guess, I would say no. This is a well-known issue with SMB. E.g.:

https://superuser.com/question…es-from-linux-samba-share

https://forums.raspberrypi.com/viewtopic.php?t=226647
https://superuser.com/question…accessible-on-samba-share
https://forums.truenas.com/t/s…why-have-i-fixed-it/10784
...and a dozen more similar threads.

It sounds like some people have managed to get this to work, but I need a solution for OMV.

I would really prefer not to go through setting up NFS — SMB is simpler — but dealing with DOS sh*te in 2025 is a deal-breaker.

When I mount a SMB share on macOS Sequoia, I see garbage filenames for some folders, e.g., _Z78J5~C. This is apparently due to SMB falling back into some DOS 8.3 compatibility mode.

I gather this is happening because some directory names end with a "." character. However, the naming of the directories is done by an app, so I can't rename them myself without breaking it.

I tried adding "mangled names = no" as an SMB config option, and the correct directory names do appear, but I cannot see any of the files inside the directory.

EDIT: I have searched the Net and found dozens of posts asking the same question, but with no resolution. It seems there was some very arcane solution that involved creating a custom "mangled map" but that was deprecated by Samba over a decade back.

Is it possible to fix this, or do I need to give up on SMB and figure out NFS instead ?

TIA

Was there ever a solution to this?

Idk why the swap partition was so small, but I launched Debian live from a USB drive and used gparted to increase the size.

Sorted.