JonathanM

So simple and yet so much better than what I have done in the past. I usually edit the xml on the VM I want to manipulate with the live ISO set to boot first, but that can have unpredictable results when the live ISO uses the existing xml. MUCH better to just add a general utility VM with gparted and other recovery tools, and change the attached disks (or preferably a copy) to whatever you need to manipulate. It's the software equivalent of mounting the problem disk in a known good computer, vs trying to boot the problem child computer with a live CD. Thank you for making me think through this, now I've got a much better strategy to deal with a number of issues that could come up.

So you have backup elsewhere? File sync makes it really easy to mess up, because you expect the second copy to magically understand when to stop syncing. Example, overwrite a document, file sync overwrites the same document. No recovery possible. Ransomware encrypts one end, the other end is encrypted as well. Entire folder deleted? Gone. You say OK, I'll only sync periodically, I can catch any errors before the sync happens and recover. No. No you can't. There are really good reasons to set up file sync, mainly to provide fast local access in 2 distant locations for people who need to actively work on the same set of files. My apologies if you already know all this, but many people think they want sync and haven't really thought through what they are really after.

Age would typically be defined by one of the available dates in the file's meta data. https://www.howtogeek.com/517098/linux-file-timestamps-explained-atime-mtime-and-ctime/ Which one to use, well that's a good question. As far as copying instead of moving, that's not a function that should be in mover, at least in my opinion. Here's why. A user share is the combination of all the root folders of that name in all the various pools and the array. If you have identically named files in the same path on different pools, you end up with an issue when you present that file to be viewed or modified in the user share. How do you decide which one to show, and what do you do with the duplicates? In my opinion, file backup should be a totally separate function, not directly linked to user shares or mover, for the reason above.

Maybe this would be a good time to reintroduce my idea for the cache and mover settings. Instead of cache yes no prefer only, how about mover jobs can specify source and destination, and shares specify initial placement. As an example, on the share settings, you would specify new files destination pool, and select which mover jobs to enable. The mover jobs would have time to start running, source pool, destination pool, file age restrictions, file size restrictions. So, a share could be configured to start on cache pool 1, and have a mover job that selects all files older than 5 days and smaller than 100MB move to pool 2 every week, and a mover job that moves all files in that share on pool 1 older than 30 days and larger than 100MB to the array every 3 weeks. Mover status could show which jobs are currently active, with cancel buttons. Yes, you could easily set up a loop where files get moved round robin and back again by accident (or on purpose). It would add a level of complexity that may be too much for some people, but with general settings that mimic the current yes no prefer only, I don't think it would be that bad, and would be WAY more intuitive than the current situation.

Which means the VPN isn't initializing properly. https://github.com/binhex/documentation/blob/master/docker/guides/vpn.md

And allow moves between cache pools.

Why? Can you give concrete reasons why you would do this?

No. Some people have issues when IOMMU is enabled at all, some have issues regardless of IOMMU being disabled. Some people have no issues at all, but when your data integrity is at risk, it's not worth testing fate.

I would think that if you are using UD devices for offsite physical backups, you would want to apply the immutable attribute to keep your backup media extra safe when you are accessing it for recovery purposes.

Can you verify the power cables are correct for that PSU? There have been instances of people thinking modular power cables are all the same, when in fact they can be very specific to your PSU and using a modular cable from another PSU can cause very bad damage.

Google this: unraid marvell site:forums.unraid.net

Then it is not available to be included or excluded in user shares.

Those are notorious for causing issues.

Unless you are not running a parity drive at all, I doubt that the bottleneck is rsync. When you are moving data from one parity protected drive to another, it's going to be slow, since you are restricted by the seek times and rotational latency of 3 drives. If you try to do more transfers simultaneously, it's going to be even slower than the cumulative speed of doing 2 transfers back to back, because you are going to be waiting on the parity drive to seek to yet another area, causing more latency. If you are willing to forego parity protection for the duration, you could definitely speed things up.

sdX designations are ephemeral, since Unraid runs from RAM and essentially is reinstalled on every boot. Use the drive's serial number to refer to the drives, as that shouldn't change.

Don't know what to tell you. I just pulled a fresh download, filled in all the initial settings, and it came right up with the database pointed at /books.

Are the permissions correct?

What does ls -lah /mnt/user/media show?

Where do you have /books mapped?

So you can easily point calibre at /books and have the files stored at that mapped location instead of stuck inside appdata.

Each additional license tier allows more attached devices. No other changes. Pricing in tiers allows you to have a lower price point for those who don't have a need for more devices. The cost difference is subsidized by those who choose to spend more for more devices. You get the same upgrade and capability benefits as those who pay much more for the top tier license, but at a discount because you are limited to fewer attached drives. The difference between buying the more expensive license outright vs. buying a lower tier and upgrading is because there is an administrative cost associated with each transaction. They are essentially providing a rebate towards the price of the higher tier when you "trade in" your lower tier license. If that discount isn't enough incentive, feel free to keep your basic license for another machine that needs fewer disks, and purchase the higher tier outright. That way you keep both licenses, and can run a second machine as a backup. At the end of the day, the Unraid license is close to being the cheapest part of a NAS build, a very small percentage of the total cost.

Have you tried

Fairly sure you have the wrong end of the stick here, but if you are dead set on changing it, I believe it's in the appdata/nextcloud/nginx/site-confs/default file. Not sure why you even want to change the port since the container has access to any port it wants on that IP, it's not like it's going to conflict with another service, which is the normal reason to change ports.

Containers with their own IP address don't use mapping. If you want to change the listening port you must do it in the app.

Don't feel bad. Container mappings are one of those concepts that everyone struggles with at first. The good thing is that once the light bulb is lit, everything just falls into place. I think the major obstacle most people can't seem to get over is related to the isolated nature of containers. It's intuitive but wrong to think that just because the container is running as an app on the system that it has access to all the resources on that system.