I recently found this docker unresponsive. I tried to remove it, as well as the image and delete the data to find that two files / directories are what look to be corrupted and will not delete. How do I get rid of these files and re-install this docker? No matter what I do I can't find a way to delete these files. They also show ? for user and attributes.

Edited March 11, 20188 yr by mikedpitt420

13 hours ago, mikedpitt420 said:

I recently found this docker unresponsive. I tried to remove it, as well as the image and delete the data to find that two files / directories are what look to be corrupted and will not delete. How do I get rid of these files and re-install this docker? No matter what I do I can't find a way to delete these files. They also show ? for user and attributes.

 

that's a host file system issue with (i believe not to be taken as gospel) fuse thinking the files are busy

stop/start the array or stop the array and reboot and try again

Rebooted, still same thing. Those files won't delete. Also, when I try to stop the array from the GUI it hangs on "unmounting disks". I don't know if that helps or not. I was able to use "powerdown" through SSH, then once it reboots I can stop the array normally. But it seems like if I try to touch those files something happens and the GUI can't unmount the array. 

EDIT: Stopped the array, ran a test on the (3 month old) cache drive and I get this: which references the 3 files I can't delete. 

checking extents
checking free space cache
checking fs roots
root 5 inode 795665 errors 200, dir isize wrong
root 5 inode 7350789 errors 1, no inode item
	unresolved ref dir 795665 index 41031 namelen 12 name nzbdrone.pid filetype 1 errors 5, no dir item, no inode ref
root 5 inode 7351526 errors 200, dir isize wrong
root 5 inode 7767099 errors 1, no inode item
	unresolved ref dir 7351526 index 11728 namelen 15 name nzbdrone.db-wal filetype 1 errors 5, no dir item, no inode ref
root 5 inode 7767100 errors 1, no inode item
	unresolved ref dir 7351526 index 11729 namelen 15 name nzbdrone.db-shm filetype 1 errors 5, no dir item, no inode ref
Checking filesystem on /dev/sdf1
UUID: 26b1367d-fbda-42ef-98e1-34189018efd9
found 233614036992 bytes used err is 1
total csum bytes: 194593428
total tree bytes: 943652864
total fs tree bytes: 593100800
total extent tree bytes: 106102784
btree space waste bytes: 185965020
file data blocks allocated: 1768305549312
 referenced 220438290432

Edited March 11, 20188 yr by mikedpitt420

9 minutes ago, mikedpitt420 said:

Rebooted, still same thing. Those files won't delete. Also, when I try to stop the array from the GUI it hangs on "unmounting disks". I don't know if that helps or not. I was able to use "powerdown" through SSH, then once it reboots I can stop the array normally. But it seems like if I try to touch those files something happens and the GUI can't unmount the array.

 

 

i'd say there's something wrong with your host rather than this being anything related to our image

I think you're right. I guess I'll start a thread. Thanks.

I'm stumped. I reinstalled Sonarr from scratch by mistake and seem to have missed a setting somewhere. (Couchpotato is working perfectly with sabnzb)

 

Sonarr is having a few issues:

1. It isn't downloading episodes of watched shows. When I manually click search the episode is added to sabnzb.

2. Under activity are 28 episodes that I already. I can see them when I search through my server and I can watch them on plex. When I try to search it says it can't find the file and when I try to remove them sonarr readds them.

3. I'm getting tons of errors

Import failed, path does not exist or is not accessible by Sonarr:

 

Attached are a sonarr log file and a screenshot of my docker mappings.

 

I don't see anything obvious with the mappings and am not sure where to look next. Can anyone help?

sonarr.txt

Why have you pulled the /downloads directory out from underneath where SAB (and everything else for Usenet) wants to be downloaded ? I don't know if that's necessarily the issue but it's better to keep it simple and inside the box if you aren't quite sure what you're doing. There's a reason why SAB has categories and separates things like movies and TV shows

Edited March 26, 20188 yr by mikedpitt420

I'm not sure what you're suggesting?

In a normal Usenet SAB / Sonarr / Couch(Radarr) scenario your downloaded files end up in /mnt/cache/appdata/sabnzbd/config/Downloads or somewhere underneath /mnt/cache/appdata/sabnzbd/

 

Again, I'm not saying this is your issue, just seems overly complicated for no reason is all

I was using this setup before. Do you have any advice on what I should change my settings to use the Downloads share I have created?

No. I try to use the programs as they're intended to avoid things like this. I don't think these mappings are an issue, I may be wrong. I am a mod on a fairly decent sized indexer. I advise loads of people each day how to setup their automation. KISS rings true all the time. Don't try to go outside the box unless you know what you're doing. Again, this may have squat to do with this issue but you aren't making it easier on yourself going outside normal directory conventions. I would just use the downloads folder as it's intended in its' intended place for what it's worth. See if that works, it's worth a try

Edited March 26, 20188 yr by mikedpitt420

ryanth - your docker container mappings are fine except I would dump the mapping to incomplete-downloads. It just isn't necessary and makes it more confusing. The container already has access to /mnt/cache/Downloads via the /downloads mapping, so there is no reason to map another directory below that. Most people put the complete and incomplete downloads all into a Downloads share so I have no idea why that SAB container has that extra /incomplete-downloads mapping point.

 

It might be a Folders setting in SAB. In SAB, do you have the temporary download folder set to /downloads/incomplete and the complete downloads folder set to /downloads/complete? You can change the incomplete and complete names if you want, but don't deviate from the /downloads/ part because it must be there to use the mapped Downloads share. Otherwise, the downloads can end up in /config which is /mnt/cache/appdata/sabnzbd on the unRAID side.

 

Once SAB does a download, check that the file is in the complete directory in the Downloads share. If you use categories then it will be in the category directory. If it's not there, then you still have the folder settings in SAB set wrong.

 

mikedputt4120 - if you want to know why I do it, it is so I can share the Downloads as public for reading and writing over the network but NOT share the appdata share at all so it can't get messed up. It is also simpler to get to the downloads when the downloads are in their own share. Besides, It's not outside the box for these Docker containers, but rather quite a normal setup.

 

 

 

Edited March 26, 20188 yr by lionelhutz

7 hours ago, lionelhutz said:

mikedputt4120 - if you want to know why I do it, it is so I can share the Downloads as public for reading and writing over the network but NOT share the appdata share at all so it can't get messed up. It is also simpler to get to the downloads when the downloads are in their own share. Besides, It's not outside the box for these Docker containers, but rather quite a normal setup.

Yes. If you have multiple dockers that need access to the same storage, you setup a common storage for them to use, and not put it all under the appdata for one of the apps.

I have noticed that whenever sonarr moves files from my download folder to my media library it spins up the array even though I have a cachedisk. I can also see that the file is written rather than moved to the new destination which is on the cache drive /mnt/cache/. (While the move is in progress I can see a .partial~ file in the destination folder).

 

Is there any way to avoid this?

 

Paths:

 

/config --> /mnt/cache/appdata/sonarr/

/dev/rtc --> /dev/rtc

/tv --> /mnt/user/media/tv

/downloads --> /mnt/cache/appdata/sabnzbddownloads/complete/

 

Thank you!!

 

Edited April 9, 20188 yr by lasers

1 hour ago, lasers said:

I have noticed that whenever sonarr moves files from my download folder to my media library it spins up the array even though I have a cachedisk. I can also see that the file is written rather than moved to the new destination which is on the cache drive /mnt/cache/. (While the move is in progress I can see a .partial~ file in the destination folder).

 

Is there any way to avoid this?

 

Paths:

 

/config --> /mnt/cache/appdata/sonarr/

/dev/rtc --> /dev/rtc

/tv --> /mnt/user/media/tv

/downloads --> /mnt/cache/appdata/sabnzbddownloads/complete/

 

Thank you!!

 

 

 

check your settings on the host regards using cache for any shares involved 

1 hour ago, sparklyballs said:

 

 

check your settings on the host regards using cache for any shares involved 

 

Thanks for replying!

 

/media = use cache disk: yes

/mnt/cache is a drive share so no cache setting I guess?

 

I feel quite lost here...

 

Edited April 9, 20188 yr by lasers

Irregardless of the use cache setting, writes to user shares will tend to spin up disks, as the system has to check to see if the folder and file being written to already exists on the array so it can overwrite if necessary.

 

Installing dynamix cache dirs will mostly alleviate this.

 

As to it rewriting vs simply moving, this is because sonarr is moving the file from (as far as its concerned) /downloads to /media.  Since those are two different mount points, any OS will do a copy / delete operation instead of a simple rename to the new folder.

 

How to alleviate this is to instead of passing through /downloads and /media is to pass /mnt mapped to /mnt to all the apps involved and then reference within each app's settings (sonarr and your dl client) /mnt/user/... 

9 hours ago, Squid said:

Irregardless of the use cache setting, writes to user shares will tend to spin up disks, as the system has to check to see if the folder and file being written to already exists on the array so it can overwrite if necessary.

 

Installing dynamix cache dirs will mostly alleviate this.

 

As to it rewriting vs simply moving, this is because sonarr is moving the file from (as far as its concerned) /downloads to /media.  Since those are two different mount points, any OS will do a copy / delete operation instead of a simple rename to the new folder.

 

How to alleviate this is to instead of passing through /downloads and /media is to pass /mnt mapped to /mnt to all the apps involved and then reference within each app's settings (sonarr and your dl client) /mnt/user/... 

 

Thank you! changing to the same path: /mnt/user helped with the rewriting, it now moves the files in a matter of milliseconds. I then tweaked my cache dir settings and now sonarr move files without spinning up the array. Thank you so much for your help! Really appreciated. :-)

 

Edited April 10, 20188 yr by lasers

i have sonarr set to chown to nobody:users, but it ends up using 65534:users. anyone else have/had this issue?

2 hours ago, harleywastaken said:

i have sonarr set to chown to nobody:users, but it ends up using 65534:users. anyone else have/had this issue?

 

If you set this in the settings of the app, it's wrong. Then it needs to be abc:abc. 

9 hours ago, saarg said:

 

If you set this in the settings of the app, it's wrong. Then it needs to be abc:abc. 

 

sorry, not sure i'm following - the Docker container is using the default of PUID 99 & PGID 100; sonarr itself is set to chown user nobody & group users. if i add a new show sonarr creates a directory for it owned by 65534:users rather than the nobody:users i'd expect.

 

taking a closer look, on unraid nobody maps to uid 99, while inside the container nobody maps to uid 65534 - most likely the mismatch is here, though i would have expected someone else to run into this issue as well. anyone else have a similar setup that's working, or should i just disable permissions in sonarr/radarr and make sure the downloaders are setting them correctly?

2 hours ago, harleywastaken said:

 

sorry, not sure i'm following - the Docker container is using the default of PUID 99 & PGID 100; sonarr itself is set to chown user nobody & group users. if i add a new show sonarr creates a directory for it owned by 65534:users rather than the nobody:users i'd expect.

 

taking a closer look, on unraid nobody maps to uid 99, while inside the container nobody maps to uid 65534 - most likely the mismatch is here, though i would have expected someone else to run into this issue as well. anyone else have a similar setup that's working, or should i just disable permissions in sonarr/radarr and make sure the downloaders are setting them correctly?

 

You have to set it to abc:abc as that is the same as nobody:users in unraid. The PUID & PGID maps the unraid user/group to the user/group inside the container.

So set chown to abc:abc if you want it to work. 

8 hours ago, saarg said:

 

You have to set it to abc:abc as that is the same as nobody:users in unraid. The PUID & PGID maps the unraid user/group to the user/group inside the container.

So set chown to abc:abc if you want it to work. 

 

got it, thanks.

Sonnar have been adding epsiodes to ruTorrent (those are added in stop mode but I can live with this) when the download finished sonnar says "eppisode missing from disk" but the files are there.

This was working in the past with other series, so now I don't understand why it doesn't work.

 

 

18-4-29 15:24:54.2|Info|SceneMappingService|Updating Scene mappings
18-4-29 15:24:55.3|Info|RefreshSeriesService|Updating Info for XXXXX
18-4-29 15:24:55.3|Info|RefreshEpisodeService|Starting episode info refresh for: [296762][XXXXX]
18-4-29 15:24:55.3|Info|RefreshEpisodeService|Finished episode refresh for series: [296762][XXXXX].
18-4-29 15:24:55.3|Info|DiskScanService|Scanning disk for XXXXX
18-4-29 15:24:55.3|Info|DiskScanService|Completed scanning disk for XXXXX
18-4-29 15:24:55.5|Info|MetadataService|Series folder does not exist, skipping metadata creation

XXXXX= hide on purpose

Edited April 29, 20188 yr by L0rdRaiden

Hey. I ran the "Fix Common Problems" plugin for the first time today and it informed me of several repos being depreciated, this being one of them. I noticed THIS link early in the thread but the link is dead. Is this posted anywhere with a different URL? I'd like to switch over to this repo, but I would really prefer not to have to start it over from scratch. I've been using it for years and it would take forever. Is there a way to switch over without losing everything?

 

Thanks