That is why I suggested borgbackup
I need to look closer at borgbackup.
Posts by crashtest
-
-
Buddy and I were talking about OMV style NAS vs. commercial cloud storage. The biggest advantage to the latter is having it remote in the event of disaster.
There's some disadvantages with data storage in "the cloud" that you might not have considered.
- Any service provider is only as good as their WORST employee. (Meaning your personal data may be sold, for a few cents, without your knowledge.)
- When a business entity goes bankrupt, there is no recourse or recovery. All might disappear in an instant. (The way Redbox disintegrated should give all pause for thought.)
If you want "remote", which is a great idea for backup, the idea you're considering is worthwhile. Further, you might consider setting up backup in a shed with power or at a distant relatives house. You'll save some money, over the long haul, and you'll be in full control. -
Sorry for the noise.
It's all good...
-
I did enable Wifi during the burning of the Debian lite image but used a wired connection during the entire install.
Use -> this process which specifically states NO WIFI. This (NO Wifi) is important because it has a direct impact on networking during the install.
(Wifi is set up as a later step - that's in the document as well.) -
I built an R-PI4, again, about 2 hours ago following the install document.
In the essentials that boils down to the following:
- Using a 2.XV of the R-PI imager and a clean SD-card
- Burn R-PI OS 64bit light. (DO NOT preconfigure Wi-Fi)sudo apt-get update
sudo apt-get upgrade -y
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash
sudo reboot
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash
After the script finishes, login to the GUI, confirm changes.
That's it. I haven't had any problems before, or after, Arron's script change.
_________________________________________________________________________
Granted the above doesn't cover all factors but it covers the image, the script, and OMV.
Variables that remain are the user's local network, router, DNS issues, the ISP, etcI think crashtest will have something to say about this.
(Other than those who insist on pre-configuring Wi-Fi, despite the doc telling them not to.)
While ryecoaaron has a better understanding of the fringe cases, other than the possibility of user induced issues, I don't understand exactly what's happening. We're talking about fixed hardware and a limited number of variables.
Beyond the initial verification of the 8 build document:
Given a couple threads like this one, I've done a few builds to check for the possibility that the R-PI foundation might have changed something that affects the build of OMV8. I haven't found anything.
If I can't replicate the issue, I can't see changing a process that is working for the vast majority of users... -
And the RPI foundation seems to like to make major changes often.
I can verify the above. In the service of hardware that never changes, the foundation's seemingly compulsive need to tinker with their image (and their imager), within the same major OS release, is somewhat mystifying.
-
The easiest approach, and the best route for all (beginner or expert), is to simply follow the build the -> R-PI build document. The outcome has been worked out in advance.
The end result can be supported, without the need to reverse engineer what went wrong with a user or internet directed build. -
Given the chance that Raspberry PI OS many have changed something with their image, I built an R-PI4 to verify these build -> instructions. I just finished the build and it worked without an issue.
Since the script relies on remote software resources, things that can interfere with builds include:
- DNS issues
- Router fire walls
- Internet (and provider) connectivity problems
- etc.
For those who may be having ongoing issues, the script's full output is needed. Putty can be configured to save screen output to a text file. See this -> web page for information on how to create a log file from PuTTY output and attach the file to your post. -
so do we actually have a OMV8 software issue here?
Since I recently built and wrote the OMV8 install process for R-PI's, using an R-PI4, I tend to doubt that there's a software issue. Did you use -> this build process?
**Note: As annotated in the build process doc, a newer R-PI imager (Ver 2.0 or later) is necessary for the build. Older imagers may fail. -
No use-case example then?
Yes... In the User Guide (how to create an SMB share that's open to all) and in the document (how to create media shares and private shares). Use the links provided above.
-
I reboot as requested at the end of the install sequence and the box disappeared from the network and I cannot log back in via ssh or can I ping the Pi.
There's a good chance that your router changed the R-PI's IP address. Go to your router and look at the DCHP addresses it has currently issued.
-
Perhaps <https://wiki.omv-extras.org/do…omv7:nas_permissions_omv7> needs to offer the explanation I'm after (when updated for OMV 8)?
In the GUI, at least at this point, there's next to no difference between OMV 7 and 8. The changes and improvements, so far, are in the backend. So, the majority of OMV7 documents will apply to OMV8.
Can you provide one example of when I would need to go into the "Storage > Shared Folders > Permissions @ myfolder" tab and adjust a user's Permissions setting? This will help me focus my research.
If you're looking for a build example to get you to "a working share" with open permissions to all users on your local network, the New User Guide has the process for building a network share here -> Creating a Network Share. If what you're looking for is to get a NAS up and running, with a simple and straight forward configuration, the New User Guide will get you started.
Otherwise, if you're looking at locking shared down, you'll need to read the permissions document. If you read the document, start to finish, it will walk you through what you'll need to know at a high level. It's starts with basics (local file and folder permissions, as they are on the server) and progresses to creating network level Samba shares that are "selectively" accessible by local users at their client PC's.
Otherwise, as chente has already said, you'll need to do some research. A subject like permissions can't be tutored, at a "down in the weeds" level, in a forum thread. -
These settings are used by the services to configure the user and group access rights. Please note that these settings have no effect on file system permissions."?
The permissions you're looking at are for (Samba) network layer services - not to be confused with the server's file and folder permissions.
There's a hierarchical, layered, effect that the -> permissions document goes over, along with recommendations on how to "keep it simple", which will help in preventing the creation of permissions conflicts and other issues. -
Thanks for keeping the thread going. I think this was productive.
-
I think the first question anyone would ask is:
Are we talking about a business server or a home NAS? -
It looks like there are some pretty good deals to be had.
-
I tried to copy the complete error, but it exceeds the 10000-character limit
Save it to a text file (*.txt) and add the attachment to a post.
-
Config SSH and then made OM8 install through Putty/SSH it worked well.
But now, I cannot access to it via SSH (access denied), only got access straight to the terminal... Do not understand....
If you followed this -> process. (Admittedly, it's a new OMV8 doc.) You would have created an admin user account to open up SSH connections, initially. Debian, when installed first, does not allow root access VIA SSH. The admin user must be used.
In any case, now that OMV is installed, you can enable root / SSH access. Go to Services, SSH, and check box for Permit Root Login. -
just installed an iso of OMV7 that I had ready to go, should I have any concerns going to 8? I just need to make an iso and should be good to go, correct?
Since you're doing a new build, go with OMV8 and you won't have to upgrade. The 8 ISO is still considered to be "Testing" but it should be coming out of BETA anytime now. At this point, Volker is working off fringe cases, unlikely to affect the majority, so I believe you're safe. And,,, you'll get all the updates that will make your "testing" version into the stable version. (Note: Where the GUI is concerned, there's nearly no difference between the two versions. Since you're using a 64-bit IBM PC, OMV7 documentation will work with 8.)
By the way, the flashmemory plugin in OMV7 has been replaced with the Write Cache plugin in OMV8 (currently: openmediavault-writecache 8.0.8). You'll need OMV-Extras and the Write Cache plugin, if using a thumbdrive as a boot drive.
-
I use AI for lots of things but it hallucinates with OMV coding quite often.
I've notice this as well, not with OMV coding but with other things that are detail oriented, but should still be simple, such as "forgetting" a required absolute path. (That one bowled me over.) Inexplicably dropping such details can make even minor shell scripting problematic. As it was explained by one AI, things like that can happen when AI's try to summarize or compress a context, while still within the same context..??
Again, while useful, AI has a long way to go.
