Xed

Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Xed

  • Rank
    Newbie
  1. Network type with what used to work (custom docker network - per Spaceinvader One video - Reverse proxy with LetsEncrypt) using "docker network create <name of network>" and choosing that as specific network causes the Docker to fail to bind a listening port on the correct network. I fiddled around with it until I tried "Bridge" as the network type for the docker and then it came up. So I am staying with 2.14 until a solution becomes obvious.
  2. Do you happen to be using a custom docker network (e.g. custom : proxynet), like with LetsEncrypt instead of the default "bridge"? This is the reason why the network does not come up properly with 3.0. I have tinkered around with this some more and choosing Network type = Bridge allows the docker to start-up correctly with a network. I don't have a solution to this if I want the Docker to be on the correct network for external access...
  3. I downgraded back to 2.14 for now, put the following string in the Repository field: haugene/transmission-openvpn:2.14
  4. Same issue, reverted to older image.
  5. I am seeing no difference if I use IP to access the share. I have noticed something else though. When I am connecting to the share via WIFI (Unifi AP), it does not take several seconds to refresh and resort the directory within Windows 10. I noticed this when I tested with my work laptop to the same share (on the same home network). I then plugged in an ethernet jack to the network and now I see the same behaviour with the laptop as well as my desktop PC. So there could be something in Windows or a network driver that is not queuing the data properly or out of order or
  6. Similar issues that I am observing with UnRAID 6.8.0 vs. 6.6.7 - Was not using 6.7.2 due to concurrent write issues observed. As I don't have a video to demonstrate 6.6.7 without downgrading my system from 6.8.0, I am showing you a similar example of the same media content but served from a Synology 1815+ over the same network (Gigabit) path back to my Windows 10 Pro PC and you can see the performance difference that I am currently observing with 6.8.0 and SMB shares. Synology performance that was equivalent to what I was used to seeing with UnRAID 6.6.7:
  7. I am also seeing this issue on 6.8.0 from a Windows 10 Desktop browsing a "Media" share with 5000+ directories with each directory having one or two media files at most. It literally takes 5-6 seconds for the directory to refresh while navigating from the sub-folder back to the media share again. I have a mirror of all of this media running in a Synology 1815+ which the same Desktop can navigate in and out of directories instantly. So this tells me it is an UnRAID problem and not something with my Desktop configuration. I did not experience this issue on UnRAID v6.6.7.
  8. So I am relatively new to Unraid but not new to Linux. I am frequently using SSH to do things that I find more efficient on command-line. Today I had a power failure and the server rebooted. After the reboot, or at least by the time the array was restarted, all my configurations were wiped, including command "history". So this tells me that root login is on tmpfs? How can I setup some preferences to survive either a reboot or shutdown/startup of the array?