tazman

Dear all, I have six ICYDOCK 5-3 MB455SPF bays of which 3 show a red HDD light in the middle bay. Red indicates a failed drive. However... According to the manual, the HDD red light needs to be signalled by the host adapter via a specific FAIL connector/cable which is not connected. So it should not be possible to be red. Moving a drive from one slot to another ie. a drive that shows green in one slot into the red one changes nothing. Removing the fan does not change anything. Switching the SATA cable does not change anything. The drives work as expected. The slot is just red, whatsoever. I could find anything online that explains this. Has anybody seen this and can advise what the middle HDD light = red means or has a tipp what I could try to debug this further? Thanks! Best regards, Thomas

I have two disks with 1 and 2 files that fail to export. I understand that an export failure is due to the fact that no hash has been generated for them. I (re)Build both drive but the error still persists. Here is one example: xfs_repair (without -n) did not do anything either. All files and can be read and copied without problems and are identical to their sources. Note, though, that the folder has actually a whopping 25000+ file in it. When I ran into this problem I had thousands of export errors on several drives. After Build, I am down to those three. I also noticed that the number of files that were reported as having an export error was not identical to the ones that are reported as added when I run the Build. Added is higher. I would have expected it to be the same. E.g. Export = cannot find the hash <=> Build = adding the hash. Appreciate your advice how to judge this and which measure to take to either assess more or rectify. Thanks!

I just upgraded. During the reboot the machine had problems during the BIOS boot and I had to turn it off again. 6.7.0 then reported one disk as "Unmountable: No file system". I am not sure if this is a 6.7.0 problem or maybe a hardware glitch. I have reported it here:

I just did a fresh install and eventually got it to run and the GUI to display. Now, my syslog is flooded with messages like this every minute: I found a possible solution here: https://serverfault.com/questions/317393/connect-failed-111-connection-refused-while-connecting-to-upstream ... but I am too noob with dockers to even grasp what to do. Within rtorrent this error message is logged: Bad response from server: (0 [error,getplugins]) supervisod.log contains: 2019-03-02 20:38:34,021 DEBG 'watchdog-script' stdout output: [info] nginx running [info] Initialising ruTorrent plugins... 2019-03-02 20:38:34,115 DEBG 'watchdog-script' stdout output: [info] ruTorrent plugins initialised What is really strange is that the error messages keep occurring even after the rtorrentvpn docker was stopped! This makes me suspect that the problem might be outside of the docker, despite the fact that it is referenced in the error message. Really appreciate a nudge in the right direction on how to get this fixed! Thanks! Tazman

I cannot connnect to the WebGUI due to a "The connection has timed out" error. after start of the container the unraid log reads: Jan 26 11:55:12 SS kernel: veth3ae72c2: renamed from eth0 Jan 26 11:55:12 SS kernel: docker0: port 6(veth76b2945) entered disabled state Jan 26 11:55:13 SS avahi-daemon[10028]: Interface veth76b2945.IPv6 no longer relevant for mDNS. Jan 26 11:55:13 SS avahi-daemon[10028]: Leaving mDNS multicast group on interface veth76b2945.IPv6 with address fe80::e01b:b9ff:fe94:cf4d. Jan 26 11:55:13 SS kernel: docker0: port 6(veth76b2945) entered disabled state Jan 26 11:55:13 SS kernel: device veth76b2945 left promiscuous mode Jan 26 11:55:13 SS kernel: docker0: port 6(veth76b2945) entered disabled state Jan 26 11:55:13 SS avahi-daemon[10028]: Withdrawing address record for fe80::e01b:b9ff:fe94:cf4d on veth76b2945. Jan 26 11:55:16 SS kernel: docker0: port 6(veth2adbcca) entered blocking state Jan 26 11:55:16 SS kernel: docker0: port 6(veth2adbcca) entered disabled state Jan 26 11:55:16 SS kernel: device veth2adbcca entered promiscuous mode Jan 26 11:55:16 SS kernel: IPv6: ADDRCONF(NETDEV_UP): veth2adbcca: link is not ready Jan 26 11:55:16 SS kernel: docker0: port 6(veth2adbcca) entered blocking state Jan 26 11:55:16 SS kernel: docker0: port 6(veth2adbcca) entered forwarding state Jan 26 11:55:16 SS kernel: docker0: port 6(veth2adbcca) entered disabled state Jan 26 11:55:22 SS kernel: eth0: renamed from veth5e2003a Jan 26 11:55:22 SS kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2adbcca: link becomes ready Jan 26 11:55:22 SS kernel: docker0: port 6(veth2adbcca) entered blocking state Jan 26 11:55:22 SS kernel: docker0: port 6(veth2adbcca) entered forwarding state Jan 26 11:55:23 SS avahi-daemon[10028]: Joining mDNS multicast group on interface veth2adbcca.IPv6 with address fe80::843:a0ff:fe94:793f. Jan 26 11:55:23 SS avahi-daemon[10028]: New relevant interface veth2adbcca.IPv6 for mDNS. Jan 26 11:55:23 SS avahi-daemon[10028]: Registering new address record for fe80::843:a0ff:fe94:793f on veth2adbcca.*. Config is: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='Transmission_VPN' --net='bridge' --privileged=true -e TZ="Asia/Singapore" -e HOST_OS="Unraid" -e 'OPENVPN_USERNAME'='xxxx' -e 'OPENVPN_PASSWORD'='xxxx' -e 'OPENVPN_CONFIG'='Hong Kong' -e 'OPENVPN_PROVIDER'='PIA' -e 'LOCAL_NETWORK'='192.168.0.0/24' -e 'TRANSMISSION_RPC_USERNAME'='admin' -e 'TRANSMISSION_RPC_PASSWORD'='password' -e 'OPENVPN_OPTS'='--inactive 3600 --ping 10 --ping-exit 60' -e 'PUID'='99' -e 'PGID'='100' -e 'TRANSMISSION_DOWNLOAD_DIR'='/downloads' -e 'TRANSMISSION_RPC_AUTHENTICATION_REQUIRED'='false' -e 'TRANSMISSION_RATIO_LIMIT'='1.1' -e 'TRANSMISSION_RATIO_LIMIT_ENABLED'='true' -e 'TRANSMISSION_RPC_HOST_WHITELIST_ENABLED'='false' -p '9091:9091/tcp' -p '1198:1198/udp' -v '/mnt/user/.incoming/!Torrents/':'/data':'rw' -v '/mnt/user/.incoming/':'/downloads':'rw' -v '/mnt/user/Public/Torrents/':'/watch':'rw' -v '/mnt/user/appdata/Transmission_VPN':'/config':'rw' --restart=always --log-opt max-size=50m --log-opt max-file=1 'haugene/transmission-openvpn' Appreciate your advice on how to debug/fix this! Thanks!

The WebUI refuses to connect in the current version or it gives a Connection failed error: There seem to be two problems: 1. PIA needs to be connected to a port forwarding host as mentioned here: https://www.privateinternetaccess.com/helpdesk/kb/articles/how-do-i-enable-port-forwarding-on-my-vpn. This fixes this error: Note, that the settings do not allow for the selection of all those endpoints. For example, there is an invalid Germany choice. Instead there should be a "DE Frankfurt" and a "DE Berlin" 2. From what I could find out there seems to be also a problem with 2.94. Reverting to 2.93 by using "linuxserver/transmission:121" into the repository and applying the change fixed this. But then, this version doesn't use PIA. Does anybody have an idea how to fix this problem e.g. by reverting to an older version of haugene/transmission-openvpn? Thanks! tazman

Hi, I am also having issues with the preclear script stopping. I am using the most recent version 2017.03.31 with scripts gfjardim 0.8.5-beta and bjp999 - 1.15b. Unassigned devices is installed and up-to-date with 2017.05.21. The progress simply stalls, no values change anymore and the disk access LED indicates that there is not activity on the disk. The GUI/server remains responsive. It's happening on different disks, controllers and with both scripts. Starting the script via the preclear plugin or unassigned devices makes not difference. It happens in the second or third cycle. E.g. my last try stalled at 95% during post-read in the second cycle. I did not observe any changes in memory or CPU usage. So I dont think the process has an issue with resources. Stopping and restarting the preclear does not work. The script says: "Starting..." and doesnt do anything. Instead it displays the following error message: /boot/config/plugins/preclear.disk/preclear_disk.sh -c 2 -J /dev/sdq root@SS:/usr/local/emhttp# /boot/config/plugins/preclear.disk/preclear_disk.sh -c 2 -J /dev/sdq sfdisk: invalid option -- 'R' The script seems to continue to run which is also indicated by this line in the log: May 26 10:54:29 SS preclear.disk: Pausing preclear of disk 'sdm' Which occurred after the pre-clear stalled and I stopped the array. I didn't see anything else bluntly obvious in the log but close to the drive the following warning occurs: May 24 10:46:35 SS kernel: sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1 To fix this a shutdown is required. A reboot is not sufficient. I initially thought that this points to a hardware issue. But I tried different controllers on my Supermicro X9SCM-F and AOC-SAS2LP-MV8 with the same results and then I saw others also reporting the script stalling so I thought I share this. I trust that the script still performs its tasks properly, so I just start another run to get to my expected cycles. So it's not a real problem for me, more an annoyance. Best regards, Thomas