remotevisitor

As has been mentioned User0 includes all files/directories on the data disks in a share, not including the cache disk. The reason that User0 exists is specifically to help implement the ‘mover’ functionality. If a share is set to cache=yes, then any files in a share on the cache disk are moved by mover to the share in User0; as the cache disk is not included this has the effect of moving the files from the cache disk to the data disks. Similarly, if a share is set to cache=prefer then files are moved from User0 to the cache disk. For ‘normal’ usage you should use the shares under User which includes files/directories on all data disks and the cache disk in a share.

And on that nfs issue you linked to, the last posting to it was from Tom over 2 weeks ago asking for a retest and posting of a diagnostics.zip on a failing system. As none were forthcoming I guess Tom is assuming the changes in the last update fixed the problem .... hence I assume Tom question "What NFS problem?". Earlier in that thread Tom had said they were unable to reproduce the problem on their systems so were reliant on affected users to supply diagnostics for investigating the problem further.

Adding the failing disk to the exclude list for being in a share (there is a global setting for this, as well as per share settings) will prevent new files from being written to that disk. But unfortunately it will not prevent writes to files that already exist on the disk. I have a feeling your cp command will create a top level folder (and therefore a data share) called disk2 on disk3 .... this share will then hide the disk share called disk2. I think your cp command should be using /mnt/disk2/*

So that you can restrict access to shares to specific users.

The license key would have been in the config directory but will have been encrypted by the ransomware. do you have a copy saved elsewhere, maybe on an email (assuming you received it by email), or a backup of your flash drive. If not then you will need to contact Limetech support directly and provide your details and ask them to transfer the license to your new USB drive and send it to you.

From your original screenshot it looks like the files on your flash have been encrypted by ransomware, which means you have at least one system on your network infected by the ransomware software. Before getting your unRaid back up you need to find what systems are infected by the ransomware and fix them, if you have not already. Be aware that when you do get your unRaid system back up, it is quite possible you will find all the files on it encrypted by the ransomware if the system infected by the ransomware had write access to your shares.

I’m afraid it is some time since I last read the official documentation so I cannot say how explicit it is in describing this. Certainly the order that the disks are currently searched I have learnt when Tom responded to a posting in the forum. What you describe will certainly work fine. Another way would be to use the Unbalence plugin to copy the files between disks for you ... it effectively generates the necessary rsync command for you and deletes the files that are transferred. It will prevent you hitting the "Data share / Disk share" problem ... Never copy files between a Data share and a Disk share (or vice versa)! This will result in the copied files being zero length. Data share to another Data share is fine, and so is Disk share to Disk share.

A data share is created for any top-level directory that exists on any of the disks in the array (including any cache drive). if more than one disk has a top-level directory of the same name, the contents are merged together when viewing them vis the data share. if files with duplicate path names on different disks exist in a share, then the file to be displayed will be searched in the order, cache disk then data disk in drive number order. [Note, it is a bad idea to have such duplicates and you should avoid them so as it will lead to confusion about which is the ‘master’ version .... such duplicates usually only occur if you manually copy (rather then move) files between disks.] The include/exclude setting only affects where new files are written; they have no effect on the location of existing file. So for example if you have files in a share on disk 4 and you add disk 4 to the exclude list, those files will still show in the share on disk 4, but any new files will be written to a disk other then disk4.

Maybe a scheduled check if changes have been made to the flash which sends a notification to backup the flash to an external location if it detects any changes might be an alternative. I guees it depends on whether such a check is practical or not.

You need to follow the parity swap procedure: https://wiki.unraid.net/The_parity_swap_procedure Read it through carefully as you must not miss any steps. If unsure, or you need additional information, post here before proceeding and I’m sure someone will be able to give further advice.

Ah ... my bad. The advice I gave only ensures that files that do not already exist on the intended cache/data disk get moved. i had forgotten that mover will not overwrite files that already exist in the destination. do you have mover logging enabled, it should have at least shown it was skipping files? Settings -> Scheduler -> Mover Settings -> Mover Logging -> Enabled.

If you have files on both cache and data disks and have the share set to cache only, temporarily set it to cache prefer and manually run mover (which will move file from the data disks to cache) , then set to back to cache only. if you have files on both cache and data disks and have the share set to cache no, temporally set it to cache yes and manually run mover (which will move files from cache to the data disks), then set it back to cache no. update: realized I didn’t address the question of which files are the ‘active’ files .... the ones on the cache disk; these setting only affect the placement of new files, not the usage of existing files which uses cache first, data disks second. Therefore for the ones set to cache no, you will probable just want to delete the ones on the data disk.

In this case I think it was a deliberate decision when the stable release was made ... see

By any chance is the folder being copied to your Unraid share a versioned backup with some files/directories having hard/symbolic links to duplicated files/directories in the backup? The difference could then be whether following such a link or not is performed when calculating the sizes/number of files; which may be controlled by a Samba configuration option.

Settings -> Display Settings -> Dynamix color theme.

Don’t confuse GB with TB.

The problem is that you put the first parameter to the cp command in double quotes which means that it doesn’t expand the "*" to the list of file names but rather looks for a file called "*". Remove the double quotes.

If I was you I would contact Limetech support to find out why you got the error when you attempted to transfer the license key to another usb drive: because it could be a problem in the future if something happens to your current usb drive and you need to transfer the license key to another usb drive. to confirm that your existing usb drive has not been added to the blacklist by the attempted transfer; if it was the usb drive will be blacklisted if you ever install any future unRaid update, better getting this clarified while you have a working system.

What is the split level set for the Photos share .... I’m guessing it is forcing things to go to disk 4 which looks pretty full. Split level takes precedence over allocation method. And/or it could be that the ‘Minimum free space’ setting on the Photo share is set too low .... should be set at least to the largest size of file that will be written to the share.

I suspect that the USB drive you were sent in 2012 contained the unRaid system and the key file was sent separately by email with instructions to copy it onto the USB drive. This would allow them to mass produce the USB drives and then process the distribution of the key file just like any other order. if you do not have the key file then you will have to contact Limetech support and provide enough details so they can resend it to you. You say that the unRaid system does not boot to a GUI .... this is expected for an unRaid system from 2012. It is only more recent versions which support a GUI login on the unRaid console. As you have mentioned that you get a login prompt then the system has actually loaded. As has been mentioned by others, you must administrate the system using a web browser from another system ... connecting to it using the URL http;//tower Personally I would find another USB drive, install the latest evaluation unRaid version on it (which will have a GUI login on the console if you select that boot option) ... you then have 4 weeks to get everything working and a copy of your original key file from Limetech. If you place the original key file onto this drive in the config directory then when you boot you will be prompted to transfer the license key to this drive.

I guess I would try as the message on the screen suggests and add the ‘noapic’ to the kernel boot and see if that makes any difference. i haven’t done this myself before but I think you need to add it to the ‘append’ line for the relevant entry in the syslinux/syslinux.cfg file on the flash drive.

As many as that .... I thought it was now about 3 actual employees with a couple of volunteer developers/testers helping out. but then I could be way wrong as I’m just going by the activity we see here on the forums.

You must have had some other problem to cause the parity error as doing operations on /mnt/disk1 updates parity.

The best way is to do the new config and select that you wish to keep the current configuration for data, parity and cache (if you are using cache). Then when you go to the main tab you can unassigned the 2nd parity (make sure it is the 2nd parity disk that you unassigned); this is because after doing the new config the main tab is still. In initial disk assignment mode (like when you originally assigned the disks when you first set up unRaid). You can double check that the other disks are assigned as you would expect from your screenshot - they should be but it doesn’t hurt to double check for piece of mind. [if you hadn’t selected to keep the current configuration of your disks when you did the new config at this point you would instead need to assign them from the information in your screenshot] Then when you go to start the array you can select the option that parity is valid. The array should then start with just the 1st parity disk. If at this point any disk comes up saying it is unformated stop, do not continue, and ask for help. Once you are happy that the system is back up and running ok, I recommend you start a parity check.

i wonder if you maybe at some point in the past you have accidentally created a symbolic link called "-a" which points to a non-existent file/directory in the stuff you are trying to copy.