dasx86

Members
  • Posts

    21
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

dasx86's Achievements

Noob

Noob (1/14)

6

Reputation

1

Community Answers

  1. Had the same issue, this addressed it for me: https://github.com/linuxserver/docker-nextcloud/issues/288
  2. Cool, welcome to the hobby! If you can set up that 5 port switch upstairs, then plug your "access point" and that PC into that switch, I think that'll address the immediate need. I think you might be putting clients downstream from the "access point" into a double NAT situation (and maybe that has something to do with your current issue?) I'm not enough of a networking guy to explain why double NAT is a problem, I just know enough to know if you put yourself in that situation unintentionally with consumer gear, problems can arise
  3. Sorry, I skimmed your first post and didn't read thoroughly enough - so I think some of what I said in my prior post is inaccurate too. But, it still sounds like you're trying to piece together a network with what you have on hand, and it's resulting in some undesired behavior. I don't think the age of the "access point router" has anything to do with it. I wouldn't recommend replacing it with the same router as your "main" router, unless that model is set up with ability to chain together multiple to "bridge and extend" another router. Not sure if you're just new to Unraid or you're new to servers and Linux in general - some people start in this hobby by running an extra laptop with an external hard drive, fast forward 2 years and they're running a setup like this guy. So if that's you, maybe this is an excuse to level up your network hardware 🤷‍♂️😆
  4. edited: I did not read the original post correctly - seems like something is going on with name resolution (NetBIOS?) This is not an SMB issue. I think by having a router (as an access point) downstream from another router, you've actually created two separate networks. I would guess that any computer connected to the "access point" cannot even ping another machine that's on the upstream router's network, and vice versa. I believe you could set up manual routing between the two, but I don't think this will be intuitive at all (if even possible) on the regular consumer gear I'm assuming you have. I would focus on investing in a better networking setup - one where multiple access points are actually the same network. I've been happy with my Ubiquiti gear. If I were in your situation and starting from scratch, I'd look at a Ubiquiti UDM Pro, plus two access points - one for where your router is now, and another for where you've extended your network with another access point. Ubiquiti makes it easy to have multiple access points on the same network. It's a bit pricey though - perhaps others can chime in with other recommendations. Good luck
  5. Don't get the Fractal Design Define XL R2 Get the new Define 7 XL! https://www.fractal-design.com/products/cases/define/define-7-xl/black/
  6. Put https:// in front of the ip:port manually, it should load once you do that.
  7. Unfortunately I've trashed my docker.img after this initially happened, way before realizing the "rootfs" destination issue we've been talking about in the last 10 posts. I've also switched from the old Krusader docker to the new one from binhex, so all of that is long gone.
  8. Ah, everything I had read seemed to be in reference to additional volumes, but it makes complete sense that it would apply to any volume. If this indeed the case... well, maybe I've missed a recommendation to point the "main" volume directly to user shares, thereby restricting the user from browsing to devices outside the array. Or perhaps the recommendation was made to use RW/slave across the board and I've missed it? Or perhaps this isn't the issue?
  9. Does anyone have any insight if this is part of the issue? eg. why browsing to /mnt/disks from /mnt within the container points to rootfs, while a separate mount that points to /mnt/disks directly does go to the partitions on drives as intended?
  10. Thanks for taking the time to write such a detailed reply, pwm. I've edited my earlier posts to accurately convey mappings as they are set up. Here's the relevant part of the docker config: Scenario 1: Point well taken. I do understand that having multiple mappings opens up the kinds of problems one can have when copying from disk shares to user shares (don't do it!) As I'm only using this docker to move files from user share to user share, OR unassigned device to user share, I don't think I'm opening myself up to that issue in this case. Scenario 2: I don't believe I've set myself up for issues here with my behavior so far, but understood how it would be easy to. I will ponder this part of your response again in the morning after a full night's sleep At the end of the day, I'll probably switch the container path "/media" to point to host path "/mnt/user", and only access unassigned devices through the container path "/UNASSIGNED" which points to host path "/mnt/disks" which is behaving just fine. I hope I can get to a solid understanding of why my current container path "/media/disks" shows my unassigned devices as folders, but points to rootfs for each of them....
  11. Please look at the path on the left side in the bottom picture, it still shows as rootfs even after seemingly diving into the disk volume...
  12. Any reason you can think of that browsing to /mnt/disks (unassigned devices) in Krusader would point to rootfs?
  13. Actually, you can see on the left side that it's pointing to rootfs, which is in memory, rather than the partition on disk which is XFS. So why is the /mnt/disks path pointing to rootfs? Certainly explains why I lost my files the first time - they were just hanging out in RAM!