remotevisitor
-
Posts
412 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by remotevisitor
-
-
See "No Key Transfers" in https://unraid.net/policies
-
I would try turning off the docker and VM service and see if it stops. Then at least you know it is something to do with them.
if it still continues, try booting in Safe mode from the Unraid boot menu, which will not load any plugins. See if it now stops.
if at any stage it stops it will then be a case of working through enabling your plugins/dockers/VMs to find which one is the cause.
this number of writes to the flash drive is certainly not normal.
-
Does seam a bit strange .
how about trying ‘lsof +D /boot’ to see what has any open files on the flash.
-
I would do an ‘ls -ltR /boot’ and look at the output to see what files have recently been changed to see if that gives any idea what might be writing to the flash drive
-
See last sentence in the UDMA CRC Errors section from the user manual. A link to the user manual can be found at the bottom right of the Unraid UI.
-
You have probably created the symlinks with absolute references which are only valid within the mappings provided inside your dockers.
Lets say you are mapping /mnt/users/Media -> /Media in a docker.
Now you create a symlink in the docker to be something like /Media/Favourites/A_Film -> /Media/Films/A/A_Film then this works fine within the docker because /Media/Films/A/A_Film is a valid path within the docker. But /Media/Films/A/A_Film is not valid outside your docker.
If the symlink had been created with relative references like /Media/Favourites/A_Film -> ../Films/A/Favourites/A_Film this it would work both inside and outside the docker because inside it resolves to /Media/Films/A/A_Film and outside it resolves to /mnt/users/Media/Films/A/A_Film.
You could work around the problem outside the docker by creating the symbolic link /Media -> /mnt/users/Media because then /Media/Films/A/A_Film would now be valid.
-
That error message is saying the directory that a symbolic link points at does not exists.
-
Look at using the rsync command with the -L option.
-
On 6/3/2021 at 4:57 PM, tnorman said:
I'll look into that. I have the plugin in to auto update the plugins running, It's saying I'm up to date. Hmmmm.....
Did your problem go away with the latest version of the plug-in, or did your problem persist? -
Should the online manual page linked to in the 1st posting be updated to include this —sparse option to save future users from the same problem?
-
Assuming the delay when accessing your media shares from Windows are not just the drives spinning up, then one thing you could try is to change the SMB setting "Case-sensitive names" to "yes" for these shares. For me this made a significant difference.
Of course once you make this change you will need to ensure that any file/folder names in any scripts or saved settings have the correct case.
-
You don’t happen to run any VMs on your Desktop?
They might be given the name of the host with the numeric postfix.
-
First thing to do is to convert the name back to an IP address. You can do this with:
nslookup DESKTOP-PC-2.localNow look for the device on your network with that IP address.
-
Instead of trying to build this yourself, look for the NoIp docker in Apps.
-
Short answer yes. But as you say it isn’t very intuitive.
The placement rules apply to new files. The mv command isn’t creating a new file, just renaming an existing file so the placement rules do not apply.
You have 2 possible choices:
- Set the Media share’s cache setting to ‘Yes’ rather than ‘No’ and mover will subsequently move the files from the cache drive to the data drives.
-
change your command to
mv downloads/some_dir/ /mnt/user0/Media/.As share views in user0 does not include the cache drive this forces the mv command to do a copy/delete rather than just a rename.
-
1
-
Request for the addition of ‘spell’.
I tend to use it when I need to bulk check text files for obvious spelling errors.
-
Maybe the information about the .ssh config on the flash drive (and maybe simple instructions like the above) should be added to the unraid manual (maybe in the Security section).
-
One cause I have seen for this problem is where the share directory on the cache/data disks have been created with a mixture of cases (eg on one disk it is called "Data" and another it is called "data".
-
"No data" in this case means every sector on the disk contains zeros (so the the parity calculations remain valid when they are removed)
in your case you have a file system on the disks showing no files .... the file system structure are data.
Also if you used to have files on the drive then the content of the files are almost certainly still there .... it is just the directory entry describing where the file is the was deleted.
so an empty file system is not the same as a disk containing just zeros.
-
If the cache disk is full then for shares set to Cache Yes any new files are written directly to the data disks in the share (not the cache disk) .... mover is not involved in this case.
-
The process is documented here in the Unraid manual (a link to the manual can be found at the bottom right of the web UI).
-
I suggest that your revert back to the version of Unraid before you performed the upgrade until you can contact support and get your license issue sorted out.
-
When you perform a license transfer the old USB drive GID is added to the blacklist built into future versions of Unraid (I cannot change the current version as that version has already been released with a blacklist which does not include your old USB).
Therefore the blacklist actually only takes effect when you update to a newer version of Unraid.
-
Not sure what is going wrong in your case.
I notice in your screenshots there is a "+" after their permissions which suggests there are some additional special access permissions such as ACL.
Are you possibly using Active Directory on your SMB connection?
Selling my license
in General Support
Posted
In the past we have had reports on the forum of people "selling" on an Unraid system to another person.
Sometime later, when the next release comes out, the buyer finds they cannot upgrade because the flash drive for their system has been blacklisted.
The seller had used the mechanism for transferring the license to another flash drive which blacklists the flash drive that was sold.