remotevisitor

Members
  • Posts

    399
  • Joined

  • Last visited

Everything posted by remotevisitor

  1. Were you using your gmail username and password to authenticate your SMTP connection to send the emails from your Unraid server? google no longer allow this (earlier this year I received a number of emails from google that they would no longer allow this from the end of May) …. You need to set up an application specific password in your gmail account and use that on your Unraid server.
  2. One thing you might also want to consider is changing the SMB setting for the share to be case sensitive (rather than the usual default of case insensitive). On my system this resulted in a significant performance boost when accessing files on the SMB shares. However you can obviously only do that if you access the files with pathnames of the correct case; in your case if the pathnames in the database have been stored with the correct case.
  3. When you said you were moving files over the network from another Linux machine, how were you doing the actual moving? I’m wondering if you copied them into /utube/PerspectiveFilms instead of /mnt/user/utube/PerspectiveFilms. This would explain both your system becoming unresponsive (root file system becoming full) and why they have disappeared after the reboot (because the root file system is in RAM)
  4. Try running ldd ./st and see if it reports any missing share libraries that it requires.
  5. Suggest looking at the encode/decode capability list at https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
  6. Try installing the "Open Files" plugin from Apps, and he run it from the Tools tab and see if that provides any help.
  7. The most likely reason I can see for this behaviour is that some program have the files open (for reading or writing). When you are moving the files to another disk using krusader this deletes the directory entry (so from your perspective the files no longer exists on the disk), but the actual space occupied by the file is not released until all programs that have the file open release their file handles on the file. This is standard Linux behaviour.
  8. First IANAL but the link to the EU ruling peaked my curiosity. While the ruling covered the sale of the license to a 3rd party, I believe the ruling didn’t cover transferring "support and maintenance". So in the Unraid case, it is possible that replacement license keys and upgrade rights do not transfer to the 3rd party purchaser.
  9. Possibly a bug in samba for previously allowing access which has been fixed in the latest version.
  10. Permissions on the directory don’t look correct, in order to enter a directory it should have the x (eXecute) permission.
  11. Try find /mnt/disk* -name "Everest*" and see what it reports.
  12. Use the Parity Check Tuning Plugin to schedule the check to only run when you aren’t streaming from plex (eg overnight).
  13. 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.
  14. See "No Key Transfers" in https://unraid.net/policies
  15. 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.
  16. Does seam a bit strange . how about trying ‘lsof +D /boot’ to see what has any open files on the flash.
  17. 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
  18. 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.
  19. 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.
  20. That error message is saying the directory that a symbolic link points at does not exists.
  21. Did your problem go away with the latest version of the plug-in, or did your problem persist?
  22. 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?
  23. 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.
  24. You don’t happen to run any VMs on your Desktop? They might be given the name of the host with the numeric postfix.