MichaIng
commented
2 years ago Many thanks for your report.
What is the filesystem type on the HDD?
findmnt -no FSTYPE -T /HTPC/MoviesClosed ZiggyPi closed 2 years ago
MichaIng
commented
2 years ago Many thanks for your report.
What is the filesystem type on the HDD?
findmnt -no FSTYPE -T /HTPC/Movies
ZiggyPi
commented
2 years ago Hi Micha,
root@DietPi-HTPC:~# findmnt -no FSTYPE -T /HTPC/Movies autofs fusebl
By the way. Plex has the ability to delete watched episodes and movies. Dont know if this helps
MichaIng
commented
2 years ago Ah, can you check again:
blkid -s TYPE -o value -c /dev/null "$(findmnt -Ufnro SOURCE -T /HTPC/Movies)"It seems to be NTFS formatted, isn't it? NTFS does not support UNIX permissions natively and Mono had an issue in such case to write files. But that should be actually solved by Sonarr v3 and the .NET based Radarr v3.
Which DietPi version do you use and which SBC/device? Generally filling the bug report template is advised, we have it for reasons 😉.
ZiggyPi
commented
2 years ago DietPi v7.6.2 Device model : RPi 4 Model B (armv7l)
And yes it is NTFS, but i have been using it for years and never had this problem before.
root@DietPi-HTPC:~# blkid -s TYPE -o value -c /dev/null "$(findmnt -Ufnro SOURCE -T /HTPC/Movies)" ntfs
MichaIng
commented
2 years ago The issue appeared with Mono v6, so in theory a package upgrade could have caused it.
Are Radarr and Sonarr at latest version (updated via their internal updater)?
ZiggyPi
commented
2 years ago I run the dietpi-update or apt update && apt upgrade. I have done it multiple times already.
The last time i used the internal updater i had to reinstall.
Sonarr : 3.0.6.1265 Radarr : 3.2.2.5080
MichaIng
commented
2 years ago The last time i used the internal updater i had to reinstall.
But are they on latest v3 now both? As said, that was an issue on older versions, so updating Sonarr and Radarr is very likely the solution.
ZiggyPi
commented
2 years ago Both up to date Sonarr : 3.0.6.1265 Radarr : 3.2.2.5080
MichaIng
commented
2 years ago Okay that should be fine.
And the permissions/modes you applied to the media directories are reported back as expected?
ls -l /HTPC/Movies | mawk '{print $1,$3,$4}'root@DietPi-HTPC:~# ls -l /HTPC/Series | mawk '{print $1,$3,$4}'
total
drwxrwxrwx root root
drwxrwxrwx root root
drwxrwxrwx root rootOkay as of mode 777 Radarr and Sonarr should have write permissions. Could you try to change owner to Sonarr, check back whether this has been applied, and then import a series via Sonarr?
chown -R sonarr: /HTPC/Series
ls -l /HTPC/Series | mawk '{print $1,$3,$4}' | head -5Permissions were set correct (sonarr:dietpi) But still not importing. See log from sonarr
2021-09-28 16:02:39.7|Warn|ImportApprovedEpisodes|Couldn't import episode /HTPC/Downloads/Complete/****.avi
[v3.0.6.1265] System.IO.DirectoryNotFoundException: Could not find a part of the path "/HTPC/Series/****.avi".
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x00164] in <533173d24dae460899d2b10975534bb0>:0
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.IO.FileOptions options) [0x00000] in <533173d24dae460899d2b10975534bb0>:0
at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,System.IO.FileOptions)
at System.IO.FileSystem.CopyFile (System.String sourceFullPath, System.String destFullPath, System.Boolean overwrite) [0x00035] in <533173d24dae460899d2b10975534bb0>:0
at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, System.Boolean overwrite) [0x00062] in <533173d24dae460899d2b10975534bb0>:0
at NzbDrone.Common.Disk.DiskProviderBase.CopyFileInternal (System.String source, System.String destination, System.Boolean overwrite) [0x00000] in <11136e1590e2463e903086340d35290e>:0
at NzbDrone.Mono.Disk.DiskProvider.TransferFilePatched (System.String source, System.String destination, System.Boolean overwrite, System.Boolean move) [0x00057] in <7834a0bc7d0841f6b5d32356705ed00a>:0
at NzbDrone.Mono.Disk.DiskProvider.CopyFileInternal (System.String source, System.String destination, System.Boolean overwrite) [0x0009c] in <7834a0bc7d0841f6b5d32356705ed00a>:0
at NzbDrone.Common.Disk.DiskProviderBase.CopyFile (System.String source, System.String destination, System.Boolean overwrite) [0x000ba] in <11136e1590e2463e903086340d35290e>:0
at NzbDrone.Common.Disk.DiskTransferService.TryCopyFileVerified (System.String sourcePath, System.String targetPath, System.Int64 originalSize) [0x00047] in <11136e1590e2463e903086340d35290e>:0
at NzbDrone.Common.Disk.DiskTransferService.TransferFile (System.String sourcePath, System.String targetPath, NzbDrone.Common.Disk.TransferMode mode, System.Boolean overwrite) [0x003ad] in <11136e1590e2463e903086340d35290e>:0
at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.TransferFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Tv.Series series, System.Collections.Generic.List`1[T] episodes, System.String destinationFilePath, NzbDrone.Common.Disk.TransferMode mode) [0x00129] in <b2ccbaa5d8e7430c8f2be515a642b6b9>:0
at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.CopyEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode) [0x00061] in <b2ccbaa5d8e7430c8f2be515a642b6b9>:0
at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeEpisodeFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode, System.Boolean copyOnly) [0x00196] in <b2ccbaa5d8e7430c8f2be515a642b6b9>:0
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportApprovedEpisodes.Import (System.Collections.Generic.List`1[T] decisions, System.Boolean newDownload, NzbDrone.Core.Download.DownloadClientItem downloadClientItem, NzbDrone.Core.MediaFiles.EpisodeImport.ImportMode importMode) [0x0029b] in <b2ccbaa5d8e7430c8f2be515a642b6b9>:0Hmm, this indicates indeed an issue with setting the file modes. Very strange as this shouldn't happen anymore. Can you check whether Mono is up-to-date?
apt install mono-runtime mono-complete
dpkg -l | grep monoAnd if you try the same for Radarr (which does not use Mono), it is the same issue? Can you share again the full logs of this?
ZiggyPi
commented
2 years ago MichaIng
commented
2 years ago Logs/pastes from console and files are btw nicer to read when wrapped into code fences 🙂:
paste multiple lines here
Indeed the issue seems to be underlying the same. Probably latest .NET core broke things again and found it's way into latest Mono already 😞...
But strange is that Mono has not seen any update since March, so I'd have expected more reports. I'll try to replicate it.
ZiggyPi
commented
2 years ago Micha thanks inadvance. If it helps Teamviewer is also an option.
ZiggyPi
commented
2 years ago @MichaIng i now see an available update in sonarr itself. Is this a possible fix for the problem. And is it at all possible to update in sonarr itself without messing things up. Apt update didnt find any updates...
MichaIng
commented
2 years ago Where do you see the Sonarr update? It might take a while until a release is pushed to the APT repository, so keep an eye on the banner notification (if you have daily APT checks enabled) or apt update.
And yes, of course you can and should upgrade the Sonarr APT package as fast as an update is available, and as long as Sonarr guys don't do a mistake, it won't mess things up.
ZiggyPi
commented
2 years ago I'm a bit hesitant as the last time i update through sonarr/radarr i had to reinstall and add every movie/serie again.
MichaIng
commented
2 years ago Hmm, was it probably the upgrade from Sonarr v2 to v3? Movies etc are stored in the database which should not be touched neither by the package upgrade nor by the internal updater. Interesting actually that the internal updater can be used when the package was installed via APT, as this may involve a downgrade when the package is reinstalled. Not sure how this is solved.
If unsure, backup the data directory first:
cp -a /mnt/dietpi_userdata/sonarr{_bak}Okay, updated it through sonarr. But still not importing completed episodes
But the last time was already on v3. Sonarr wasnt reachable after the update. Rebooting rpi or restarting didnt work so i did reinstall, that didnt work so i did an uninstall and install thinking that i could put back the backup, but that was gone as well... thankfully i also have everything in my phone on the seriesguide app.
ZiggyPi
commented
2 years ago @MichaIng any progress on a solution?
MichaIng
commented
2 years ago It works fine here, importing via Sonarr into an NTFS mount (formatted and mounted via dietpi-drive_manager) after:
chgrp -R dietpi /mnt/media
chmod g=u -R dietpi /mnt/mediaYou have the ntfs-3g driver installed, right?
apt install ntfs-3gIn case, the fstab entry:
UUID=2B514D5B573D8190 /mnt/media ntfs noatime,lazytime,rw,permissions,big_writes,nofail,noauto,x-systemd.automountYep ntfs-3g newest version and my fstab looks the same the only diffetrence is the "/mnt/media" mine says "/HTPC" if i look in /dietpi/mnt/ i cant see my mount. It is under /dietpi/root/HTPC.
But as far as i know it has always been that way
MichaIng
commented
2 years ago Ah dammit, I totally forgot about the systemd-wise hardening. Please do the following:
/mnt or below /media.mkdir -p /etc/systemd/system/{sonarr,radarr}.service.d
echo -e '[Service]\nReadWritePaths=-/HTPC' > /etc/systemd/system/sonarr.service.d/extend-write-paths.conf
echo -e '[Service]\nReadWritePaths=-/HTPC' > /etc/systemd/system/radarr.service.d/extend-write-paths.conf
systemctl daemon-reload
systemctl restart sonarr radarrCompare also with our docs: https://dietpi.com/docs/software/bittorrent/#sonarr
In Using custom download/media directories tab. Prefixing a path with a dash - allows the service to start even if the path does not exist. The above commands do basically the same, just with a dedicated config file.
ZiggyPi
commented
2 years ago Okay so i changed my HTPC mount to /mnt/HTPC and changed the symlink accordingly.
Now sonarr imports the episodes but it doesnt delete them from deluge. They stay queued.
MichaIng
commented
2 years ago The letter is done via Deluge API, so that shouldn't be affected by the restrictions. I cannot test it currently as on my test systems Deluge does not start downloads and I don't want to open ports to testing systems 😉. I see downloads were done to /HTPC/Downloads, so the same mount and now hence /mnt/HTPC/Downloads?
Isn't it also a setting in Sonarr/Radarr whether to keep (for seeding) or remove important downloads?
ZiggyPi
commented
2 years ago I changed some bandwidth and queue settings in deluge and it works perfect again. So this issue is resolved 👍
MichaIng
commented
2 years ago Great. Probably we should relax the Sonarr/Radarr/Lidarr hardenings a bit to not R/W protect everything outside of the ReadWritePaths list 🤔.
ZiggyPi
commented
2 years ago Yeah thanks very much for your help.
And yes i think that relaxing the hardening would have saved me a lot of headache. But yet again, good oppertunity to learn some new stuff and setting up my mount better 😁
This week i began having issues with Sonarr and Radarr not importing completed downloads from Deluge.
The sonarr log gives an error "unable to create directory". So that seems to be a permission issue.
So i tried the obvious... chmod -R 777 /HTPC HTPC is the link to my external HDD with HTPC/Movies and HTPC/Series.
Both are root:root, i also tried sonarr:root, sonarr:dietpi and dietpi:dietpi
But i still get the same error.
I have a suspicious this happend after an update.
Any help is appreciated. I now have to create folders and move files manually :cry: