stealth82
-
Posts
172 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by stealth82
-
-
I noticed that if I make use of the pcie_acs_override instruction in the syslinux cfg of the boot key (I need to define pcie_acs_override=id:1022:43c6 to split a particular IOMMU group) and I go under Settings > VM Manager, even without touching anything, I am immediately welcomed by the warning banner that says a reboot is required.
If I change any of the settings in this page the pcie_acs_override instruction in the syslinux gets wiped out and I need to add it again before rebooting otherwise I am going to lose it.
Can this particular case be handled more gracefully?
-
-
OK, I believe it's the same problem. It's writing on disk1 because it can't do it in any of the pools.
That's why the only-cache type of share can't be created whereas the prefer does; it's able to create it on disk1 of the array while failing to do it on the pool disk but at least it can "deal with that".
At the same time shfs - is this the process that shows all the disk folders as one under /mnt/user, right? - isn't able to read data from any of the pool disk directories. And yet the webGUI is able to show it (see attached screenshots).
-
😞
I'll keep on trying.
Regarding the ssh, yes, it's hardened and root is not password enabled from outside.
-
Yeah, that's a separate problem that just popped out now as I went through a cycle of stop start array, and there it was, a nice surprise...
I recovered the data, though I am not sure something got corrupt..., and reinitialized the drive, I will have to copy data back to it.
I tried to change from cache only to cache prefer and I was finally able to create the shares. Only... it's now writing exclusively to disk1 of the array and never to the pool. Moreover I have data in the pool disk that should fall under the user share and it doesn't show anything!! What's going on???
-
I'm using unRAID 6.9.
I have 2 pools: cache, and lone, each one with only 1 disk.
I tried for the first time to create a share (see screenshot) using the cache pool lone, but I have been unable to.
This is the error I see in the syslog:
May 15 14:16:11 Tower emhttpd: shcmd (1409): mkdir '/mnt/user/public' May 15 14:16:11 Tower root: mkdir: cannot create directory '/mnt/user/public': No medium found May 15 14:16:11 Tower emhttpd: shcmd (1409): exit status: 1 May 15 14:16:11 Tower emhttpd: shcmd (1410): rm '/boot/config/shares/public.cfg'
If I create a share using the array disks it just works.
I already tried several things, stopping-starting the array, restarting the server, creating the share using the other pool named cache, but nothing. I also search the forum for solutions, found similar threads, but all of them without a useful answer.
Why can't I create a pool-only share?
-
On 12/24/2017 at 5:37 PM, natecook said:
BTW, I am still having this issue with settings/preferences not saving. I have three separate instances of the Transmission Docker, two old and one brand new. The older two have saved settings from back when I could adjust and they'd save, and the newly created docker just reverts to the default settings.
My settings also don't stick
-
I should have read that post before...
Anyway I did the adoption step and all is good now. Thanks for your repeated help
-
2 hours ago, Djoss said:
Ok, so I think that if you let gfjardim's container update itself to the PRO version and then you switch to my container, it should work.
You could also try to change central.crashplan.com to central.crashplanpro.com in conf/my.service.xml (while the container is stopped).
I did let gfjardim's container update to the PRO. Before turning the container off I checked it out and saw that it was upgraded (blue color and Pro written somewhere).
After that I turned the container off and followed the readme in the first post of this thread.
I changed the host but the problem remains.
I guess I didn't read well since I now notice you were supporting transition from your own crashplan home container...
-
1 hour ago, Djoss said:
From mine or gfjardim's container?
Also, in conf/my.service.xml, what is the value of the authority tag?
cat /mnt/user/appdata/CrashPlanPRO/conf/my.service.xml | grep "authority"
gfjardim's.
<authority address="central.crashplan.com:443" hideAddress="false"/>
-
1 minute ago, Djoss said:
Are you re-using a fresh appdata or it comes from a previous installation?
Previous installation
-
On 8/27/2017 at 6:09 PM, Djoss said:
Do you copy-paste your password? Which webpage URL are you using?
I used the WEBGUI and I have the same problem. I even dumbed the password down but it keeps on saying the info is incorrect.
My account credentials work just fine with the official crashplan pro dashboard. What could the problem be?
-
Same here. I had 75GB to back up. I started yesterday, it ran form 5 hours. It backed a few GB.
This morning I resumed it: it's been 9hrs, I still have 45GB to back up. Unusable!
-
Thank you!
-
It worked! Thanks!!!
But does that mean that I will have to do that again in case of future docker update or its installation from scratch?
-
My transmission config has
"script-torrent-done-enabled": true
"script-torrent-done-filename": "/config/push.sh"
The push script makes use of curl but it's been some time now that I noticed the binary isn't to be found in the docker... it used to be there before...
If I type
docker exec -ti transmission /config/push.sh
It returns:
/config/push.sh: line 55: curl: not found
Was curl recently removed? Or has docker changed with more recent releases of unRAID?
-
I have a question but it's not strictly related to the docker itself? Hope it's not too off-topic...
When Plex docker network is configured as Bridge Plex takes a docker network IP in a range that is obviously different from the hosting unRAID one - e.g. the home network is 192.168.1.* and Plex is under 172.17.0.*.
Although mapping the Plex port exposes the server to the home network Plex Server keeps the internal IP as a reference.
Now everything seems to be working OK until you want to verify how close your Plex server is: if I'm under the home network I would expect the server to be considered nearby - same local network (that's an info you see if you have an iOS app and check what server you're connected to). Unfortunately the server is labeled as remote and not nearby. This screws up with the way content is served - direct play, profiles, etc...
Any suggestion on this? Has this problem been considered before?
-
Instead of going the xml modification route, can't append vfio string also be used - as it currently is for PCI pass-through devices - to automatically insert and show through the GUI the identified USB controller?
-
This made me think that it would be nicer to have a turbo writer option per share...
Let's say that I would activate it in case I'm copying movies and TV shows, but not in other cases where the normal files size is relatively small.
Maybe it doesn't make sense. Maybe it would make more sense if unRAID could determine the file size that is being copied beforehand and decide, above a certain size limit, to trigger the turbo write mode.
-
Besides the Xonar?
-
By the way, why would you want to pass the onboard audio through?
-
I mean that I'm quite sure it will still throw the error he's experiencing.
As far as I could see the Xonar, PCI version in my case, won't share the vm with any other sound card. Either it alone or nothing.
Anyway, I would be tremendously happy to be proved wrong regarding that.
-
If he does the VM simply won't start as it doesn't now.
-
Is your Xonar PCI or PCIe?
Don't pass the AMD HDMI Audio.
Still, if your VM finally boots successfully you MIGHT find yourself dealing with garbled audio from your Xonar and VM + unRAID severe lockups.
Hope that doesn't happen to you and it's just my hardware to be unholy. If it is going to happen to you, also your hardware is unholy.
Passing through PCI Sound Card
Unable to create pool-only share (SOLVED)
in General Support
Posted
I had noticed that but thank you for pointing it out. That happened on a new disk I installed just the other day to replace one that started counting pending sectors last week. In conjunction with that I shrank the array by reassigning the pulled drive as a pool drive. So there’s been a lot of moving/copying while parity was also rebuilding. I think I should have gone for a less reckless approach and do things in sequence rather than in parallel…
I started the scrub process now. Hope everything will turn out well…