itimpi

The screen shot you posted shows that the system did attempt to write to the logs folder on the USB drive (which should be mounted as /boot). If you think it is not there then please post the output of the 'df' command so that we can check that the USB stick is correctly being mounted during the boot process at /boot.

The screen shot you posted shows that the system did attempt to write to the logs folder on the USB drive (which is mounted as /boot). If you think it is not there then please post the output of the 'df' command so that we can check that the USB stick is correctly being mounted during the boot process.

The file you provided provides nothing useful. If you want any useful feedback then you are going to need to provide the system diagnostics zip file. This can be obtained via Tools->Diagnostics from the GUI or using the 'diagnostics' command in a console session to write it to the logs folder on the USB stick.

The file you provided provides nothing useful. If you want any useful feedback then you are going to need to provide the system diagnostics zip file. This can be obtained via Tools->Diagnostics from the GUI or using the 'diagnostics' command in a console session to write it to the logs folder on the USB stick.

There have been lots of posts of this type of behavior. When working at the Linux level If the client thinks source and destination are on the same mount point then the move is first tried as a rename and only as a copy/delete if that fails. In this case the rename is working and the file stays on the cache drive but in a new folder. you either need to configure things at the container level so that the source and target do not seem to be on the same mount point so the move automatically runs as a copy/delete operation, or (which tends to be easiest) set the User Share to Use Cache=Yes so that mover later moves the files to the array.

What type of network card is being emulated? If the default of virtio then the OS will need a virtio network driver loaded before it can access the network. If not already present this would normally be loaded off the virtio CD image.

Did you also spot the fact that the mapped volumes should be set to the 'RO/Slave' or 'RW/Slave' options?

Glad that at least one problem is fixed The only thing I can suggest is to delete the network.cfg file from the config folder on the USB drive and then reboot it to get a new default one generated. If necessary then customise the network settings to suit you.

As far as I know this feature has always been there (well at least since Unraid v5 which is when I started with it). The only thing I can remember that changed was making it default to non-correcting rather than correcting. Any time Unraid cannot successfully unmount the drives there is quite likely to be some invalid sectors on the parity drive so I cannot see why a normal user would EVER want this feature disabled. The correct solution is for you to resolve what is stopping the unmounting from succeeding so the shutdown completes cleanly. What are you using to trigger your unmount scripts - maybe that is where the issue lies and they are not getting run successfully?

The only reason that this should happen on a tidy shutdown/reboot is if Unraid cannot update the status on the USB stick. The alternative is that you are not actually succeeding in doing a tidy shutdown. It may be worth putting the USb stick into a Windows/macOS system to get it to check the USB stick. The diagnostic you posted also shows two issues that should be resolved: - The syslog is flooded with messages about a network error - disk3 is reporting read errors With the above two issues flooding the syslogs it is difficult to spot any other error messages (if any) that might be relevant. Since you are running 6.7.0 rc7 it may be possible to get more information about what is happening when you attempt to shutdown/reboot by setting Unraid to act as its own syslog server keeping with the results to be stored on the USB stick.

No idea then, it looks like you have done everything correctly just a thought though - did you copy/paste when setting up the entry? If so it might be worth deleting the entry and typing it in manually as copy/paste has been known to insert hidden characters which can upset things.

Are you sure that the container has been built to expect its GUI to be exposed on port 80? What type of networking have you set up for the container (host/bridged/custom). If have set the networking to host have you set up any port mapping to avoid clashing with Unraid's use of Port 80 for its own GUI?

Perhaps the options reading something like: - update ready (instead of ‘updated’) - apply update (instead of ‘update ready’) would be clearer and less likely to lead to confusion (and not take up more space)?

The one thing that seems to frequently fail on a 2GB system is trying to do an OS update via the GUI. This can fail if there is not enough free RAM to unpack the new release into RAM before writing the new release to the USB stick. The workaround in such a case is to use the manual update method. The basic NAS functionality seems to work without issue on a 2GB system.

You should ask this question in the support thread for this docker - it does not seem to be a general Unraid issue.

Interesting question. I was writing to the flash from my parity.tuning plugin every time a parity check was paused or resumed and I was asked if I could reduce that frequency (which is of the order of hours apart) ! I think this is only likely to be of much concern for those who have largish dives where a preclear can take many hours (or even days if doing multiple passes). I would guess something like 30 minutes would be a good compromise between keeping the number of writes down and not having to repeat too much of the preclear on a resume.

Looks interesting - but since its primary purpose seems to be testing/debugging would it not probably belong in Dev Pack rather than Nerd Pack?

Another way to approach this might be to download one of the later 6.x vmdk's where the partition size seems to be 1GB, and then copy the contents of whatever Unraid release you want to use on top of the existing contents.

The cut-overs are based on the largest disk. Since that is 4TB the first cut-over is 2TB. However since no drive is larger than 2TB and the 4TB drive still has 2TB free no cut-over occurs. As was said the next cutover-point will be 1TB. You willthen get 1TB written to each of the 2TB drives.

I have changed the vdisk size on VMs without the effect on the network that you describe. I expect that there is something else going on in your case. i would not expect the ‘df’ command to show anything different until you have run an appropriate partition management tool (e.g. gparted) inside the VM under Linux. Unraid may increase the physical size of the emulated disk but it will not touch the partitions/file systems on the vdisk - that is up to the VM to do so.

I have used both NoMachine and RDP with Linux VMs so I would say those suggestions are both relevant.

That is a subset of the information returned by the CLI level 'uptime' command. Perhaps you had not realised that 'uptime' is a standard command?

Fair enough. However in this case I want an existing built-in page (not customised) to also use the revised version of the script so my way may still be appropriate? I did check that the existing script is only called from one place in the current GUI, and since the script simply populates a pop-up it will not affect normal operation.

I had not seen that mentioned previously - I must add it to my developer notes. Which plugin folder - the one in RAM or the one on the USB stick? Does this apply when it is not a .page file but is instead (as in this case) a script (from the dynamix include folder) that is being replaced?

That would not work with the way I currently handle it What I do at the moment when the plugin is installed (either on first install or after a reboot when a fresh copy of Unraid is loaded into RAM) is rename the standard one *by adding .orig to the name) and then set up a symbolic link with the old name pointing to my customised version. If you uninstall the plugin I reverse that procedure. This avoids the need for me to currently save anything about the built-in version. I need to think whether storing a checksum or a copy of the file is easier to handle (assuming I bother with a version check at all).