Doing a clean install will produce the same "SMB shares not browsable on network", as experienced by petaramesh, so I won't bother doing it.
Without trying a clean rebuild, I don't know how you know this.
In any case, I can't reproduce the problem. My regrets.
Likewise, I am experiencing this problem on a Raspberry Pi 4 that I upgraded from OMV 6.x to 7.x.
First, it should be noted that the OS (on your SD-card) should copied for backup ( -> Cloning Flash Media ).
Second, things can go wrong with a version upgrade. (Before attempting an in-place upgrade, "things that can go wrong" is a very good reason for backing up the SD-card.)
__________________________________________________________________________
I just performed a fresh (from scratch) build of OMV7, on an R-PI 4, and reconnected to data that existed on a drive from an OMV6 R-PI4 build. The SMB Music share was there, browsable on the network, almost immediately after the SMB share was enabled. (Shared folder permissions are "Others - Read". SMB is "Guests Allowed").
Perhaps, at this point, a -> rebuild is something you might consider.
Thank you but i have already installed it.
Unfortunately, without logs and other details, no one could know "how" you installed it. You might consider reinstalling using the method referenced.
OMV7 RPI4 cant get putty ssh to work i get network error permission denied..
If you follow the install process found -> here, in the process, you'll enable SSH and you'll create an administrative username that can access your R-PI over SSH.
I saw you were looking at my thread. Thank you!
I wasn't quite sure what to tell you but it seemed as if it the original error seemed to be related to hardware and/or BIOS. I have an older server that, on one occasion, had an issue with a Debian 4 backports kernel that caused my CPU fans (dual Xeon's) to run at full speed all the time. I suspected it was related to BIOS or the generation of CPU which (if it was to be corrected) would have to be addressed up stream. As it turned out, an older kernel fixed the problem until a newer kernel version came out.
With the above in mind, in your case, I was thinking about recommending:
1. Installing OMV-Extras
Note: Before installing the following plugin; use System, Update Management to update OMV and the OS.
2. Under System Plugins, install the Kernel Plugin This plugin exists in OMV6 and OMV7.
The Kernel Plugin will allow you to select any available Kernel to boot from and (after a kernel has been selected and booted into) it's possible to remove other kernels. (I would keep at least one old kernel, especially if it worked before. Kernels take up very little space and, sometimes, an old kernel is a fall back that might bail you out.)
Depending on your hardware, BIOS and Debian kernel upgrades, the Kernel Plugin may be of use to you in the future. The additional one time utilities like Gparted, Clonzilla, or SystemRescue may be useful as well.
This might be what you're looking for -> NAS Permissions.
However if you are using SnapRAID it might not react well to moving files between drives.
That's an excellent point.
strangest thing was that I was able to smbget content from the SMB host but the GUI of the Mac app Finder was blank
That's interesting. Unfortunately, without a Mac, I can't test anything but (as it seems) all OS's have their quirks.
Evidently my basement is the right environment.
That might be what it was, in my case. Mine were subjected to heat and other less than desirable (dry and dusty) conditions.
Funny you'd mention CD's. With the dye pack layered disks, I've had failures in less than 10 years and that was with good storage conditions.
I have a usb 3.5" drive.
I still have one of those. That's what I tried to read my old disks with.
I just fired it back up recently because I wanted to hook a 5 1/4" floppy drive to it
What could you possibly have stored on a 5 1/4" floppy? 
I tried reading an old 3.5" floppies, about 15 years ago, and it was error city. I'm guessing floppy media life was something like 5 to 10 years max.
EVGA 132-CK-NF79 from 2008 with Intel Q6600 from 2007 : )
You beat me by a year or so. My Intel server (SC5650HCBRP) was launched in 2009. It's still healthy, running OMV and ZFS in RAIDZ1.
It doesn't seem like anyone understands why SSH suddenly became disabled but I got it working.
Without a rebuild to confirm, the above not completely accurate. There's a process for building on Armbian Bookworm covered -> here. While there will always be exceptions to a general rule, there's no accounting for a near endless list of variables introduced by users, user locations versus software servers, differences in hardware platforms, LAN setup details, DNS issues, etc. However, if the build process is followed, it works 98% of the time.
On other hand, you're partially right. In the 2% exception cases, without being able to sit in front of a console connection logged in as root, it can be difficult to figure out what has gone wrong based on user describe symptoms.
Therefore, I stayed on that nightly version of Bookworm Minimal.
It is still running flawlessly. =)
Make sure you clone your SD-card before doing OS updates, plugin updates, changes or additions, or significant NAS configuration changes, just in case. (Insurance never hurts.) Odds are, you'll be fine.
I have installed on an orange pi 5 plus many times without this issue.
Since I don't have one, that's what I was looking for.
Minimal.
Do you remember if you did updates and upgrades, before running the script? As in the following?
apt-get update
apt-get upgrade -y
I'm using the install script from Github but it ends with an error:
Which variant did you use? Cinnamon, XFCE or Minimal?
I'm trying to install OMV7 on Armbian Bookworm, version 24.5 released a few days ago.
What Armbian Device did you install to?
But can someone explain the behaviour anyway?
You're asking that someone explain the behaviors of a misconfiguration. There are reasons (more than one) why ExFAT, NTFS, HPFS, etc., etc., are not supported.
- Linux filesystems and the Linux kernel do not map permissions, one to one, with Windows filesystem permissions.
- The permissions used, between the two OS's, are as different as the administrative accounts that create and own the volume, and it's files and folders. Administrator - Windows versus root - Linux
- Your ExFAT filesystem is a foreign volume. (It wasn't created by the OMV / Linux server). Just because Linux identified the file format doesn't mean that it will be fully compatible. It won't be.
In your case, there's another package involved (SMB) that adds yet another layer of network level permissions on top of the file / folder permissions that are assumed to POSIX (Linux) compliant. Finally there are other misc. factors like Proxmox and running OMV in a VM. There's no knowing the details of how that's configured.
In the bottom line, non-Linux filesystems running on a Linux server will have issues that range from "marginally working" when wide open permissions were set up on the foreign volume, all the way to "no-workie". The only time plugging a foreign non-Linux volume into a Linux server is useful is when copying data from the drive (read-only is the only requirement) to a Linux drive (where permissions will be set in accordance with the server's create mask.)
The advice remains the same. Use a Linux filesystem like EXT4 and there won't be a problem.
The Banana PI M1 Armbian build is a "Developers Only" build that is not officially supported.. A "Developers only" message is clearly stated when SSH'ing in. If Armbian doesn't support their OS build, the OMV project cant' support it either.
What you're referring to, "power management control" and other hardware characteristics are clearly an Operating System and / or a hardware issue. OMV, as an application that installs on top of the OS, can not change the OS or hardware characteristics. As an example, an Odriod HC4 "reboot" in OMV's power options doesn't work. An HC4 will shut down but it won't physically (or logically) disconnect from power. To "reboot" it's necessary to physically toggle the power input. (However, the reboot option is still in OMV for hardware that supports it.)
If there's an answer to your M1 question, you might have a better chance of finding it in the Armbian Forum.
Finally, it should be noted that external hard drives have quirks of their own. Some external enclosures will power down (or power up) drives completely absent from OS commands and, in some cases, they filter out ATA drive commands and SMART data. In short, there's the potential for a number of extraneous factors related in your issue.
Only by setting it to SMB1 ( highly deprecated) can I get the Mac to see the OMV host
This is (probably) the only solution. Mac OS 10.6 (Snow Leopard) came out in 2009 - 15 years ago. SMB2 was introduced, by Microsoft in 2006 but it wasn't widely adopted, outside of the Windows circle, for a few years. In essence, Mac OS 10.6 probably shipped with SMB1. It's possible that SMB2 might have been a package upgrade for OS 10.6 but that would assume that your Mac was kept fully up-to-date until support was suspended roughly 12 years ago.
If you find the use of SMB1 to be disturbing, it might be best to upgrade the Mac.
ZFS or BTRFS can indeed build RAID disk arrays, but they do not support RAID-5 mode.
With ZFS, RAIDZ1 is the equivalent of mdadm RAID5. Three disks or more will create an array.
I assumed that all server should have the same revision/version. But.... no.
Unfortunately, this has been noted before.
