itimpi
-
Posts
20,127 -
Joined
-
Last visited
-
Days Won
55
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by itimpi
-
-
The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.
-
Are your sure there are no power related issues? A parity check would be a time of maximum load.
-
The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened leading up to the crash. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.
-
2 hours ago, totuk said:
So I think I know what might have caused that, which is that in the beginning the share was configured with the Secondary Storage with Mover. I just experienced the same behavior with `domains` share.
Even though it is stored ONLY in Cache now (I changed that) the calculation shows it resides in the Array:
You should not change it to only be in the cache until you have successfully moved all the files to the cache. Changing to that setting only applies to where NEW files are stored and does not cause existing files to automatically be moved. Mover ignores any shares which are set to use only the cache even when there are files for that share that are located elsewhere.
-
1
-
-
According to the syslog in your diagnostics those shares relate to devices that are being mounted by Unassigned Devices.
-
2 hours ago, SSD said:
An option of detecting an attempt to copy a file from a disk share to a user share and omitting the disk share from the possible destination has been suggested and hopefully Tom will comment on whether that or something similar is possibl
I think the underlying issue is inherent in Unraid in that the User Share level is not visible when working at the physical drive level.
Isn’t an easier solution to always use something like Dynamix File Manager to handle the copying/moving as it will not allow you to mix User Share and Disk Shares in the same command.
-
39 minutes ago, tuxbass said:
What if file is copied from say /mnt/disk1/dir/file to /mnt/user/dir2/dir/file?
The problem only occurs when you accidentally copy the file to itself. (e.g something like /mnt/disk1/dir1/file1 to /mnt/user/dir1/file1). In your example that is not happening so you do not encounter the bug.
-
48 minutes ago, Zonediver said:
"When" will this bug be fixed? Or: Will this ever be fixed?
The question is whether it is even a 'bug' in the strict sense of the word! The word 'bug' is used in this context to mean that it is not the behaviour the user expects even though the system is behaving as designed. It is intrinsic to Linux when used with Fuse file systems which Unraid uses to implement User Shares) so barring a major change to Fuse it will probably never get fixed.
This is one of the reasons that Disk Shares are disabled by default on Unraid as it reduces the chance of a user encountering it by accident. However even that does not help when a user is bypassing the User Share system by working directly at the Linux level either via the command line or a docker container.
-
You can set the Disk Shares SMB Export option to “Yes (hidden)” to stop them being visible on the network but still accessible if you know the name.
-
19 minutes ago, tuxbass said:
Is copying from disk share (eg /mnt/disk1) to user share (somewhere under /mnt/user) guaranteed to result in data loss?
Would only the copy target be lost, or also the source (data on disk1)?
The problem arises from the fact that /mnt/disk and /mnt/user can be different views of the same files. The effect of the bug is that you end up copying the file to itself which results in it being truncated to zero size (and thus the file contents are completely lost).
-
3 hours ago, Lev said:
The copy keeps running out of space on the first disk in the UserShare. I exclude the disk and it makes no difference, still keeps trying to copy to it. I delete >100GB of files, still keeps trying to copy to it. It will not go on to the next disk in the UserShare until I set SpiltLevel back to default (disabled) 'split any directory'.
This is probably because the Split Level wins any contention for which disk to use.
-
This sounds like a filezilla issue rather than an Unraid bug? Have you reported it in the support thread for that application?
-
Since the settings for each share are stored in different .cfg files on the flash drive difficult to see quite how this could happen! Does not mean, however, that some strange sequence of events cannot cause it.
-
Ideally you should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.
Having said that, the syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.
-
Do you even have an appdata folder (even if empty) on the listed drives? If so (check first it is empty) then deleting them using something like Dynamix File Manager will stop them being listed.
-
Do you have macvlan enabled for docker networking? If so you need to make sure bridging is disabled on eth0 to avoid potential system instability.
-
There is a good chance that the reason for the crash is the hardware ID of passed through hardware has changed so you are now passing through something critical to Unraid functioning. Hardware IDs changing is not at all unusual when upgrading particularly if there is a significant upgrade to the underlying Linux kernel in the new release.
Have you tried removing any hardware current passthroughs and redoing them after the 6.12.10 upgrade, rebooting Unraid to make them take effect, and then seeing if the VM will start?
-
I expect that is inherent in the fact that Unraid is based on Linux and the pre-clear stops a system ‘sync’ call from completing.
-
1
-
-
looks like your server might be using macvlan networking? If so to avoid stability problems you need to either switch to using ipvlan docker networking or disable bridging on eth0
-
1 hour ago, Haeldar said:
Is it best to rollback to 6.12.8 or will there be a hotfix for 6.12.9?
For the time being you need to revert. Any ‘hot fix’ would get a higher patch number (e.g. 6.12.10).
-
It should be 'pool' rather than mentioning 'cache' as that is just a pool of that name.
-
The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.
-
Once you get the red ‘x’ which means a write to it failed for some reason and the data disks and parity are no longer in sync then Unraid stops using the drive until the status is cleared by a rebuild as documented here in the online documentation.
could not spot any issues in the SMART report in the logs but you could run an extended SMART test if you want to be sure. By far the commonest cause of this type of issue is the cabling (either power or sata) not being perfectly seated so you might want to check that out.
-
Just found you can get a similar error if the host path is set but there is nothing in the server path field.
[6.12.10] Cannot fork: Resource temporarily unavailable
in Stable Releases
Posted
Never heard of this being possible, but the only way to be certain would be to contact support,