-
Posts
5040 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by NAS
-
-
I cant see anything but I wanted to check to make sure since this is such a long thread. I am in the process of migrating to XFS and I have found that one RFS disk that will mount happily with unraid wont mount at all with UD.
dmesg shows
[Tue Jun 19 15:40:36 2018] REISERFS warning (device sdc1): sh-2021 reiserfs_fill_super: can not find reiserfs on sdc1
so before I get into this are there any know relevant issues?
Update: well it turns out its pretty obvious why UD cant mount this reiser disk.... thats because it is xfs.
# file -sL /dev/sdc* /dev/sdc: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors, extended partition table (last) /dev/sdc1: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
any ideas why UD is trying to mount a XFS disks as ResierFS?
-
https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/
" After tweeting this article out @benhall pointed out that actually the
ro
setting on the volume mount doesn’t have a lot of effect in terms of security. An attacker with ro access to the socket can still create another container and do something like mount /etc/ into it from the host, essentially giving them root access to the host. So bottom line is don’t mount docker.sock into a container unless you trust its provenance and security… "In general security terms you know things are fundamentally not right with a generic approach when your trying to herd this many cats just to make it less insecure... not secure... less evil.
-
There is always a risk of breakout of any container but this is the holy grail hack of such a system.
But to be clear what this sock feature does. Essentially it gives the container root access as a member of the docker group on the HOST machine.... not the container... the host.
This is a specific feature required by the traefik container and not required by almost any other container. It is very very very rare and for good reason.
-
No I am specifically referring to the exceptional requirement of this container to activate the docker socket feature. This is very unusual.
-
Long story short if someone roots a container with docker socket enabled its pretty much game over. This is why, much as I think traefik is a beautiful piece of engineering, is build on a hill of sand.
-
https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html
Worth a read (or one of the countless other links explaining why this is very bad) before you commit to this as a solution.
-
On 5/3/2017 at 5:43 PM, primeval_god said:
Netdata can, but the docker container requires rw access to the docker.sock to do so .
If we are advocating the use of this container to fix a core OS limitation we need to explain the serious security implications of docker sock access. At the very least this will require a zone like setup with networking to mitigate some security risks.
I would in my day job always advise strongly against any solution that could have public facing containers on the same instance as a backend sock instance
- 1
-
Great. Its non ideal but at least now I know. I honestly have been wracking my brains what I was doing wrong. Time for me to move to XFS completely then.
Lets close as resolved. Appreciated.
-
Sorry I should have said, 6.5.1.
-
Any thoughts on this. Best case scenario is that it is PEBCAK but it doesnt seem to be obvious if it is. The only thing I can think off I do differernt than "some" is I often use "/mnt/cache" rather than "/mnt/user/" although I dont see why this would cause spin up on.
As an illustration here is a before and after performing a single docker container stop. Notice the parity come up as well. Comparing write counts before and after (sorry I edited them out by mistake) I can see most of the RFS disks write count increase by 7 or 8. I am wondering if this is some sort of spin up caused by the docker container issuing a disk flush such as SYNC and RFS handing that differently than XFS.
This is really annoying so any insight would be very much appreciated.
-
To be fair so did I for many years but I realised the 90% of my "mc" sessions were between 2 or 3 base locations so once I figured out the solution above I just setup a few aliases and now its second nature to type "unmcm" for "unRAID Midnight Commander Movies".
-
yes, if you are working with array files you should run mc as the typical array file owner nobody and not root.
If you try to do this mc will complain without above fix.
As a example of my usage for content only
sudo -u nobody mc /mnt/user/downloads/ /mnt/user/movies/
-
I am in the process of cleaning up years of unRAID tweaks.
The way unRAID ships when you install mc and run it as "nobody" you have problems.
This fixes it for me and some variation could probably fix it for everyone. I dont remember if mc is shipped native, if not it should be.
#==================================================================================================== #Fix mc running as nobody #==================================================================================================== /usr/bin/mkdir -p /.cache/mc /usr/bin/mkdir -p /.local/share/mc /usr/bin/mkdir -p /.config/mc #====================================================================================================
-
I now have a mixed array of reiser and xfs disks and I can confirm that when I stop a docker container, if the array disks are spun down ONLY the resier disks spin up.
Is this a known issue or a config specific problem?
-
emHTTP bombed hard as soon as I hit reboot to apply the update here. Had to force a reboot from command line with the obvious consequences.
I was having addon issues before hand though where updates would fail to apply due to the addon claiming not to be installed.
Probably a me specific issue rather than a problem with the release.
Update: my addon issue was specifically related to Advanced Buttons deprecation which I was sure i removed but somehow had not. Fix here
- 1
-
LT are wrong then But seriously I think all we need here is normal nix separation of error states. The reason I bring this up is that after manually tracking down where cache space had gone i noticed that i have had mover errors for weeks so this is based on real world issues.
Also it is not my experience here that it only runs once but PECAK is entirely feasible. Will pay more attention and report back.
-
Some quick feedback. I am new to this plugin.
First off my compliments. It is super useful and very powerful
Couple of enhancements for consideration:
- we suggest turning off mover logging which makes sense except that it also removes mover error logging.. we should not be hiding errors. not sure what the best fix would be here.
- when you enter the settings dialogue it actually kicks off a scan. I would suggest this is a break with the GUI design model and that entering settings should be limited to just that. Activating a scan should be a positive user action especially since it can take tens of minutes to complete.
Kudos
-
CVE-2018-1057: Unprivileged user can change any user (and admin) password
Caveats and further info here
https://wiki.samba.org/index.php/CVE-2018-1057
- 3
-
Sorry for the slow reply. I actually had this installed but did not realize it covered dockers as well.
I still think this should be a standard feature but you have to choose your battles especially when such a good plugin exists... deja vu conversation.
Thanking you saarg
-
There are certain containers I do not wish to always update due to either their risk of breakage or required uptime.
A good example is TVheadend which is known for breaking and updating turns of home TVs.
Currently the only way i know to not update this container is to stop using the "update all" feature and manually update each remaining containers manually one by one.
This is a chore and ideally specific containers could be excluded from "update all" or set to to only update every xx days/weeks.
- 2
-
-
14 hours ago, limetech said:
I think we can fix this behavior.
Sounds good. I think it makes more sense this way.
-
That makes more sense however i would still recommend against casually manually suggesting editing a system config file that is controlled by the gui.
Exceptional circumstances likely preclude this ever happening though so in that light some more context and warnings need applied.
here be dragons
It also needs clarity that the no SSL settings does not mean no SSL port
good work
-
7 hours ago, ljm42 said:
USE_SSL="auto" PORT="80" PORTSSL="443"
Couple of thoughts on OP.
Do we want to be suggesting using notepad or console when the GUI controls this file and does these changes for you?
Do we really need to tell people to reboot the entire server perhaps there is a softer way?
It does not work for me via the gui or by hand anyway. The best I can achieve is when it is set to this
USE_SSL="no"
PORT="80"
PORTSSL="443"port 443 is still held by nginx and trys to redirects to 80 e.g.
443/tcp open ssl/http nginx
|_http-server-header: nginx
|_http-title: Did not follow redirect to http://TOWER.local:80/which makes me think it really does mean "dont use SSL" but still listen for it and force to non TLS. I dont think this is the natural assumption of a "disable" SSL option?
Edit: confirmed if i change the SSL port via the GUI and change SSL as well i can disable SSL without rebooting. This is better albeit i still question why there is no option to stop listening on the port. (perhaps PEBCAK TBC)
ISCSI Support
in Feature Requests
Posted
Coincidentally I was thinking about this the other day along with S3 and it seems, to me at least, that whilst everyone will make a case for features they want, adding protocol support is the one sure fire way to attract new users. I cannot quantify how many users this would be but we can say that every user in the world that wants iSCSI or S3 doesnt buy unRAID.
Seems like an "easy" win to me.