Synology-Forum.nl
Packages => 3rd party Packages => SickRage => Topic gestart door: Blenetic op 04 januari 2018, 14:57:56
-
dit is de waarschuwing die ik krijg in Sickrage, werkte perfect hiervoor maar nu opeens niet meer. Er zijn geen instellingen veranderd.
2018-01-04 14:48:08 Thread-14 :: Unable to open /volume1/video/Downloads: OSError(13, 'Permission denied') / [Errno 13] Permission denied: '/volume1/video/Downloads'
-
De user waaronder SickRage draait zal dan wel de verkeerde machtigingen hebben op de map /volume1/video/Downloads
-
Enig idee hoe ik zou kunnen oplossen?
-
Als je het package draait dat ik gemaakt heb moet je de group "sc-media" lees/schrijf rechten geven op die folder.
-
die map staat onder video en bij sc-media staan de lees/schrijf rechten aan
-
Als daar nog subfolders staan van voor deze instelling houden die de oude rechten.
En files die in een folder gezet worden krijgen de rechten van de folder mee.
Je moet met FileStation die rechten resursive goed zetten.
-
opgelost! Bedankt voor de hulp
-
Dit probleem heb ik ook gehad en het aanpassen van de sc-media user loste het in eerste instantie even op. Nu is het echter weer terug, ookal heb ik niets veranderd dat ik me kan herinneren.
Het enige dat ik hierover weet is dat SickRage draait onder user "sc-sickbeard-custom". Deze user is onzichtbaar in DSM. Via Putty is deze echter wel zichtbaar middels o.a. het commando
cat /etc/passwd | cut -d":" -f1
Deze user heeft bij mij alleen rechten op de mappen "surveillance" en "photo". Geen idee hoe dat is gekomen. De zichtbare user "sickbeard-custom" en de groep "sc-media" hebben lees/schrijfrechten in o.a. /video.
Ik heb een nieuwe user "sickrage" aangemaakt in DSM en deze in de groepen "users" en "sc-media" geplaatst. Daarna de sickrage config aangepast zodat onder deze user werd gestart. Vervolgens startte SickRage niet meer op. Dus de vorige users maar weer teruggezet in de config.
Wat ik heb gedaan om dit opnieuw op te lossen is heel simpel door via Putty de map "video" alle rechten recursief op 777 te zetten.
Dat doe je door als "admin" in loggen en dan het commando
sudo chmod -R 777 /volume1/video
uit te voeren.
Hierna werkte SickRage weer zoals het hoort.
-
Je hebt gewoon een ander package draaien dat niet geschikt is voor DSM 6.
DSM 6 heeft een andere manier om met rechten om te gaan en al jouw actie hebben geen enkel effect.
Het enige wat effect had is de rechten op de video map voor alles en iedereen open te zetten (777)).
Blijft de vraag of dat nu wel zo slim is, maar dat is voor je eigen beoordeling.
Ik zou zeker niet iedereen aanraden dat zo te doen.
-
Zeker niet de beste oplossing, maar zo erg is het niet in dit geval.
Dat mijn versie niet voor DSM6 was wist ik niet.
Voor wie geïnteresseerd is in de DSM6-package van Ben(V):
https://github.com/BenjV/SYNO-packages
en de link naar de info over deze package op dit forum:
https://www.synology-forum.nl/sickrage/sickrage-package-voor-dsm-6/msg216833/#msg216833
Bedankt voor je inzet Ben(V) :thumbup:
-
Heb dit probleem op het moment ook. Snap werkelijk niet wat er nu misgaat. Het is na de update naar 6.0/1. Heb de package die hier staat aangegeven gedownload en geinstalleerd. Werkt allemaal naar behoren, permissies gaan dat echter niet, terwijl ze wel zijn gezet.
Iemand een idee?
-
Het is na de update naar 6.0/1.
Gebruik je dan wel het nieuwe package van Ben(V)?
-
Het is na de update naar 6.0/1.
Gebruik je dan wel de nieuwe package ?
Heb de package van Ben(V) gepakt en geïnstalleerd en in Sickrage geupdate. Volgens mij zit dat wel goed.
Merk overigens dat het probleem zich ook voordoet bij NZBget en Couchpotato. Ze kunnen alles onder volume1/homes/ niet meer vinden. Permissies zijn wel gezet voor zover ik kan zien.
-
Aangezien je een overzicht laat zien waar s-sickrage in staat heb je echt een ander package geinstalleerd.
Als je mijn package had gebruikt had je die user niet kunnen zien, omdat die hidden is.
-
Aangezien je een overzicht laat zien waar s-sickrage in staat heb je echt een ander package geinstalleerd.
Als je mijn package had gebruikt had je die user niet kunnen zien, omdat die hidden is.
Ok. Heb nu Sickrage verwijderd, reboot gedaan, maar sc-sickrage staat er nog gewoon tussen.
-
Uiteraard, de meeste packages ruimen hun user niet op.
Zelf weggooien dus.
-
Uiteraard, de meeste packages ruimen hun user niet op.
Zelf weggooien dus.
Hoe dan? De user is onderdeel van de system internal user groep. Kan niet achterhalen hoe en waar dit aan te passen.
-
Op de commandline met het commando:
sudo synouser -del sc-sickrage
-
Op de commandline met het commando:
sudo synouser -del sc-sickrage
Gisteren de user verwijderd. Zal vanavond jouw package nog eens installeren.
Het is mij ook opgevallen dat ik een algeheel permission probleem heb. NZBGet, Couchpotato, Transmission en mijn vriendin ( :lol: ) hebben geen van allen toegang tot mijn homes map, terwijl de permissions volgens mij correct staan.
De map gisteren ook via Putty en chmod 777 alle rechten gegeven, maar mag geen baat hebben.
(https://i.imgur.com/H6Kzmra.png)
(https://i.imgur.com/9Q8Bk2D.png)
(https://i.imgur.com/9Q8Bk2D.png)
(https://i.imgur.com/M8yboCt.png)
(https://i.imgur.com/BksfF9x.png)
Heb Google af zitten struinen, maar zie door de bomen het bos niet meer. Waar gaat het mis?
-
De homes map moet je ook afblijven dat is een share die van DSM is en is afgeschermd met ACL's.
Onder de homes map staan de home folders van de users (met dezelfde naam als de user) die als je als user bent ingelogd zichtbaar is als home (let op het ontbreken van de meervoud s).
Als je rechten wilt uitdelen moet je dat daar doen.
-
De homes map moet je ook afblijven dat is een share die van DSM is en is afgeschermd met ACL's.
Onder de homes map staan de home folders van de users (met dezelfde naam als de user) die als je als user bent ingelogd zichtbaar is als home (let op het ontbreken van de meervoud s).
Als je rechten wilt uitdelen moet je dat daar doen.
Ik moet het dus anders gaan inrichten? Heb deze NAS sinds 2013 en het toentertijd op zo een manier ingericht dat alles onder de homes folder in admin terecht komt.
(https://i.imgur.com/i7Atg41.png)
-
Klopt, onder Homes moet je helemaal nooit zelf iets doen, daar staan de home folders van gebruikers en die worden door DSM aangemaakt en beheerd.
Je kunt veel beter zelf een gedeelde map(=share) aanmaken en daaronder die folders plaatsen.
Dan geef je de groepen sc-media en sc-download rechten op die share en dan zou het moeten werken.
-
Klopt, onder Homes moet je helemaal nooit zelf iets doen, daar staan de home folders van gebruikers en die worden door DSM aangemaakt en beheerd.
Je kunt veel beter zelf een gedeelde map(=share) aanmaken en daaronder die folders plaatsen.
Dan geef je de groepen sc-media en sc-download rechten op die share en dan zou het moeten werken.
Duidelijk, ik ga er iets mee doen. Dien ik de packages ook daar geinstalleerd te hebben? In die nieuwe folder?
-
Package installeer je op een volume en niet in een folder.
Alle packages komen in een hidden folder(@appstore) op dat volume terecht.
Je hoeft dus helemaal niets met die packages te doen.
-
Jouw package geïnstalleerd, nog steeds Echelon als developer. sc-sickrage is ook weer terug. Is er een manier om dit op te schonen/weg te krijgen van de NAS?
-
Wat bedoel je?
sc-sickrage is gewoon de user waaronder het package draait.
Dat je echelon als developer ziet komt doordat de je de SynoCommunity als package server hebt geinstalleerd en zij hebben als developer echelon staan voor een package dat SickRage.
Dat is een lang verhaal maar in principe een andere versie, dus nooit updaten want dan krijg je iets dat niet werkt.
De SynoCommunity heeft besloten na een hoop gedoe om het SickRage package weer aan Echelon te geven en Sickbeard-Custom voor andere clones te gebruiken.
Alleen zijn die packages nog niet geschikt voor DSM 6 en heb ik dus zelf package gemaakt met de toen beschikbare source(niet echelon versie).
-
Ik zou bij het installeren van het package (https://github.com/BenjV/SYNO-packages/blob/master/SickRage DSM 6 noarch V1.0.spk) dat jij hebt gemaakt het volgende moeten zien toch?
(https://i.imgur.com/jezG9DQ.jpg)
Dat zie ik niet. Probeer het alleen maar te begrijpen, dus sorry voor de vele vragen...
NZBGet heb ik werkend, alle andere pakketten nog niet. Het is nogal een gedoe dus.
-
Dat klopt maar je hebt de SynoCommunity als package-centre op je NAS staan en dus gaat DSM op zoek naar package met de naam SickRage en als hij die vind haalt hij informatie daarover op.
Op zich geen probleem zolang je het package maar niet update.
-
Krijg het hier maar niet werkend. Sickrage package van Ben(V) geinstalleerd. Oude users als sc-sickrage en sc-sickbeard-custom etc verwijderd via ssh. NAs herstart.
De downloads map voorzien van sc-downloads en sc-media met lees/schrijf rechten. Maar zelfs met een kale SR installatie (zonder terugplaatsen backup) kan ik bijvoorbeeld bij manual postprocessing de downloads map niet openen......
Begin gek te worden hier. :'(
Oke de downloads folder kan ik nu weer benaderen via SR.
via shell de downloads map aangepast:
user/group aangepast: chown root:root downloads/
alle rechten gegeven: chmod 777 downloads/
Nu nzbget weer werkend krijgen. die valt nu weer over rechten :silent:
-
Sinds vandaag ervaar ik hetzelfde probleem. Deze ochtend werden Sabnzbd en Sickbeard-Custom vanuit de Synocommunity geüpdatet. Sindsdien kan ik de mijn "downloads" map niet meer bereiken vanuit Sickrage, wat tot voordien uitstekend werkte. Sabnzbd downloadt wel nog goed, maar de postprossing die ik via NZBToMedia doe liep fout, wat mij ertoe aanzette om het even te controleren.
De enige passende oplossing is dus Sickrage verwijderen en herinstalleren via de package van BenV of lees ik deze thread verkeerd?
Dankjewel!
-
Nee dat begrijp je verkeerd.
SickBeard-Custom werkt tegenwoordig ook gewoon want deze is inmiddels door de SynCommunity geschikt gemaakt voor DSM 6.
Nu moet jij alleen daar nog geschikt voor gemaakt worden. :D
Lees deze twee wiki pagina's eerst eens door.
https://github.com/SynoCommunity/spksrc/wiki/Permission-Concept
https://github.com/SynoCommunity/spksrc/wiki/Permission-Management
-
Dank voor je reactie, Ben(V)
Ik ben echt even quick & dirty gegaan en heb het zo ingesteld nu:
(https://s9.postimg.cc/bdgvfvz1r/screenshot-synology_5000-2018-05-19-10-47-38.png)
en toch heb ik geen enkel succes als ik in wil inloggen op die map via sickrage. Ik blijf volgende errors terugvinden in m'n log:
2018-05-19 10:49:41 ThreadPoolExecutor-0_0 :: Unable to open /volume1/downloads: OSError(13, 'Permission denied') / [Errno 13] Permission denied: '/volume1/downloads'
Dat probleem heb ik bij geen enkele andere map, waarbij de machtigingen overigens veel strenger staan:
(https://s9.postimg.cc/n3uswzhgv/screenshot-synology_5000-2018-05-19-10-52-21.png)
Heb je nog bijkomende tips voor me?
-
Extra super tip :!:
Probeer je screenshots hier zichtbaar te maken.
-
Google images waren wel zichtbaar bij mij, heb ze nu geupload op postimage en eerdere post aangepast. Kan je daarmee verder?
Dankjewel!
-
Het is leuk dat je de rechten goed zet, maar als je bestaande folders gebruikt dan hebben die nog de oude rechten.
En bestanden die gedownload worden en daar neergezet worden krijgen de rechten van de folder waarin ze neergezet worden.
Dus:
Ga met FileStation naar die folder en zet de permissies goed en doe dat recursief voor alle subfolders en files.
(vinkje links onderaan).
-
Dat had ik initieel reeds gedaan.
Op niveau van /volume1/downloads staat het ook allemaal correct maar kan ik het niet recursief aanpassen.
(https://s9.postimg.cc/rsfe67lu7/screenshot-synology_5000-2018-05-19-12-59-37.png)
Als ik de onderliggende mappen wil editeren gaat dat wel, maar staat volgens mij ook alles correct?
(https://s9.postimg.cc/660dp7pun/screenshot-synology_5000-2018-05-19-13-05-39.png)
(https://s9.postimg.cc/z8ens26zj/screenshot-synology_5000-2018-05-19-13-06-45.png)
Het is op dat niveau /volume1/downloads dat SickRage niet wil verdergaan, of ik het nu op de groep sc-download of sc-media zet. Op niveau van /volume1/Filestore en /volume1/web ervaar ik dat probleem niet.
-
Lees nu eens die wiki door waar ik je de links van gegeven heb.
met name het laatste stuk van deze over ACL support
https://github.com/SynoCommunity/spksrc/wiki/Permission-Management
-
Je hebt gelijk Ben(V), dat heeft de klus geklaard. Ik had dat afgeschreven als "niet van toepassing", omdat er geen Windows-laag mee gemoeid was, maar de Microsoftoplossing heeft dan uiteindelijk wel geklaard.
Heel erg bedankt voor je kwalitatieve én snelle feedback!
-
Heeft ook niet zoveel met Microsoft van doen.
ACL's zijn al veel ouder dan Microsoft, alleen Microsoft heeft ze bij het ontwikkelen van Windows NT ingevoerd (nagemaak van VMS van Digital Equipment), omdat ze een veel fijnere permissions setting toelaten dan hij vrij basic Linux systeem van owner, group en world.
Daarom heeft Synology ook besloten ACL's in DSM te gaan toepassen.