tshorts

Not manually no, just removed the shares after moving the files between shares. But it's the new shares structure that's on the cache disk. Oh, maybe. Didn't consider they can override. None have explicit access to disks, just shares, but perhaps a "bug" somewhere. I'll do some digging there. By your post I understand it's not normal behavior. Thanks!

After I merged 4 older shares into 1 new one, almost whole of that map structure is on cache disk, folders only, no files. Both old and new shares were array only. Location: cache Last modified: 7 days ago Total occupied space: 0 B in 8415 folders and 0 files While the share has about 10,000 folders. Is this normal? I've deleted the old shares, so I can't check if it was the same on the old and don't remember. Is there a risk? Share warning says "Some or all files unprotected", I'm guessing that's a false positive. But I also dare not delete the folders manually from cache (is that safe?). Last change on the file structure for that share on the cache disk is about a week ago, which is around the time I migrated, so it seems whatever put them there don't put them there anymore.

Looks like we're not using the same container. Repository for mine is: lscr.io/linuxserver/transmission You can try "Add another Path, Port, Variable, Label or Device" Config Type: Variable Name: UMASK Key: UMASK Value: 000

@comet424 Since I also since recently have issues with the transmission docker and the permissions it gives: What do you have under UMASK here in the container settings? That should be 000 (that equals 777 for folders, and 666 for files, or drwxrwxrwx / -rw-rw-rw- ), and the container variable SHOULD be the authority regarding the dockers umask, not the settings inside the applications settings file. Except it doesn't start at all when I set it to 000. So I'm curious if the same applies to you. (If you gonna try it, make a backup of the appdata-files first cp -r /mnt/user/appdata/transmission /mnt/user/appdata/transmission.bak , it broke my torrents after reverting back to 022, and had to restore that directory to restore the torrents (restore: mv -f /mnt/user/appdata/transmission.bak /mnt/user/appdata/transmission ) edit: Updated to latest transmission version now, and nothing broke when changing to 000. Either a bug in that last container version that was broken that's fixed in the latest, or just one unlucky try. I'd still do a backup before you change the umask setting though. A lot of work manually restoring until I remembered I had a backup. But remember to change it in the container settings above, not in /mnt/user/appdata/transmission/settings.json, it's authoritative and recursive to the app settings. While app settings is not recursive to container settings. BTW. I think the UMASK 022 (drwxr-xr-x / rw-r–r–) was changed with an update of the container, and was 000 before (transmission has always written files with drwxrwxrwx / -rw-rw-rw- for me until very recently), that would explain why you get another permission when you move. If you downloaded the file when container was at umask 000, and moved it when container had changed to umask 022.

You only edited settings.json and not the UMASK variable in the container settings? Weird, changing settings.json did nothing for me. Can you check what UMASK is set under your transmission container settings (it's under "Show more settings")? edit: BTW, it didn't crash by changing container settings to 000 after I updated transmission to latest transmission version that came today or yesterday. So all good in the hood now!

Transmission has been chaotic for me last couple of weeks. It went into orphan when adding new share, and I had to re-install it. After that everything creates with wrong permissions: Folders: drwxr-xr-x Files: -rw-r--r-- Changing umask in /mnt/user/appdata/transmission/settings.json didn't affect it. Found you can change umask in "Update Container". Changed it to 000, I stopped being able to connect to transmission. Changed it to 001. All torrents updated to same "added on" timestamp and and get stuck in status "Queued" and set the download directory to /root/download/ ...wft. It's all totally broken. By stuff like umask that shouldn't affect anything at all. edit: It also can't download anymore after correcting umask. It keeps downloading at full speed but doesn't write anything to disk, it seems to download and send it into nothingness. With umask 010. it starts to download again if I change back to umask 022. But...with the wrong permissions (the umask 022 permissions above where only server root can change the files)

I've had this running DDNS updates to cloudflare for a few years without issues. "Cloudflare-DDNS" https://hub.docker.com/r/ghcr.io/akarys42/cloudflare-ddns-docker But stopped working about two months ago, unsure if it's cloudflare that's made a change (perhaps removed API key, in favor of API tokens), and above project now is perhaps(?) deprecated. But when try the others, none of the other dockers works. "dns-updater" https://hub.docker.com/r/qmcgaw/ddns-updater/ No place to enter API token or domain, so didn't expect it to work, but hoped for some web overview to enter it but it didn't start at all "Cloudflare-DDNS-config" https://hub.docker.com/r/timothyjmiller/cloudflare-ddns Doesn't start, doesn't log, so don't know what the issue is. "cloudflareddns" https://github.com/hotio/cloudflareddns/pkgs/container/cloudflareddns This is the closest, I know it reaches cloadflare and finds its zone ID. But the trace ends at "unexpected error" so don't know where to go from there. (Cloudflare-token is "All zones - DNS:Edit" in case that's the issue) Any docker that work? And if so, how?

This was the reason btw: https://forums.unraid.net/bug-reports/stable-releases/lost-nvidia-driver-after-upgrading-to-720-r4167/

Did anyone's Jellyfin break when updating unraid from 7.1.4 to 7.2.3 or 7.2.4? Mine broke when I updated in February, so I just rolled back due to lack of time, and it worked fine again. Just checking in if it can have been a known error, or if I should plan for many hours (fault handling) when I try update unraid again, instead of a quickie.

Lost 150-200 torrents when updating Transmission. Usually update containers around once a month, this time it went some months before updating. But when doing so, 150-200 torrents disappeared. About 5 of 30 torrents added yesterday was still there, all other torrents added from 2025-02-06 until update was removed from the Transmission client, if all torrents before that date is still there or if I lost random torrents at those dates as well I don't know. How can I avoid that from happening again? Would stopping transmission manually before update have saved me?

But they are still constantly accessed (read/write) on the SSD only, with array as secondary right? Or do unraid sometimes chose to read/write directly to the secondary outside of the scheduled move? Like if it believes the SSD bus to be full or something.

I'll write out my (miss)understanding of it, in scenario Cache = SSD, Array = HDDs, mover scheduled at 09:00 (am) every day. Cache only: All data stored on SSD only, all read and writes is made on SSD. Array only: All data stored on HDDs only, all read and writes is made on HDD. Cache Primary, Array Secondary, Mover Cache -> Array: All read and writes are made on SSD. At 09:00 every day whatever is on (that share part of) SSD is moved to HDDs. Cache Primary, Array Secondary, Mover Array -> Cache: All read and writes are made on SSD. At 09:00 every day, what's happen then??? Array Primary, Cache Secondary: Never a reason to use? Also, why do alternative 1 vs 3 matter in regards to performance, if all read and writes are made on SSD no matter what (except a short period at 09:00)?

Okay, I'll try cache only and see if I see some improvements. Thanks. Still do not understand why, like at all. It's only a form of backup function running once a day (if scheduled for once a day), no?

I've been a user of unraid for several years now, but I've honestly never understood the Cache -> Array, Array -> Cache thing. Think I've just used some random recommendation. My brain does not seem to be compatible with understanding its function no matter what I read or watch about it. Now that I have some slowness issue with a docker I'm looking at it again. Both appdata and system is Primary storage: Cache, Secondary storage: Array. appdata is Cache <- Array system is Cache -> Array But it should always be Cache -> Array if primary storage is Cache right? All changes is done on Primary storage I presume, so moving Secondary to Primary overwrites all the changes made on the Primary....? But the function to move from Secondary to Primary is there so it's obviously something I don't understand, and I've never had any issues with configurations made having to be re-made because mover have over-written the Primary with the old configurations on Secondary. Also read someone saying they should be Cache only - but all that does is remove redundancy if Cache disk fails, no? Another said they should be Array -> Cache for better performance - then I'm back at zero for the understanding, why would moving backup/secondary to active/primary once a day make for better performance?

I just deleted everything in appdata not installed anymore. Still works. I'll kick this open if it dies at reboot.

I've had it installed before when using nextcloud, but removed it. It's still there in appdata/mariadb/, and I see it takes up half of my cache drive. So I'd like to delete it, but I don't know if I dare. It's not installed by default right? Everything in appdata is supposed to be put there by ME adding a docker? (Just realized every single docker I've tried out still lingers in the appdata)

Anyone know how I find or reset the password for a user? I'm logged in with it on a few clients, but want to log in to a new one, and need to know old password to change it. The password field in users/username.json is salted, don't know if it's possible to change it to clear text there?

It's impossible to accidentally become an exit node with this? No matter if I forget to change, or misunderstand a parameter, I can never become an exit node? I'd like to support the network, but really don't want to be an exit node. For obvious reasons.

Thank you! That was exactly it. Had to "Add another Path, Port, Variable, Label or Device" under the container, add "/mnt/user/Video - Files/" in host path and "/Video" in container path, and then run docker exec -i ffmpeg-nvidia ffmpeg -i "/Video/The.Video.Input.File.mp4" -c:v h264_nvenc output.avi and works like a charm! Your help here will probably help me with a lot of docker stuff I've never gotten to work.

Anyone managed to encode with nvenc codec in unraid with ffmpeg? I've installed ffmpeg using this guide. And it worked fine when encoding. But only with CPU encoding, when trying with hardware accelerated codec (nvenc since it's a nvidia card in the server) it does not recognize the codec. I've tried nvenc encoding on both windows and linux before and it's horrible getting to work, and unraid is another layer away from linux - if it's difficult on a standard linux distro, you'll have to add extra steps on top of that to meke it run on unraid (for things run in the native linux environment that is). Have anyone tried and succeeded to get nvenc encoding to work on unraid? I've also tried the docker ffmpeg-nvidia but that one does not even recognize the input file. Neither with full path in command, eg: root@unraid:~#docker exec -i ffmpeg-nvidia ffmpeg -i "/mnt/user/Video - Files/The.Video.Input.File.mp4" -c:v h264_nvenc output.avi Nor navigating to the directory and only run the file, eg: root@unraid:/mnt/user/Video - Files/# docker exec -i ffmpeg-nvidia ffmpeg -i The.Video.Input.File.mp4 -c:v h264_nvenc output.avi Both output error /mnt/user/Video - Files/The.Video.Input.File.mp4: No such file or directory and The.Video.Input.File.mp4: No such file or directory respectively. Anyone managed to use the docker successfully?

I just want to announce, in case other experience similar issues in the future. That I've replaced the parity disk with the relocated sectors with a new disk, and all instability issues have ceased. It's now been up for a week. While the longest before was like 2 days before hard reboot was needed. Sometimes several times in a day.

Unfortunate. I tried the built in smart self-test that went Completed without error, perhaps different the disk isn't so bad as scrutiny say it is, and 36% doesn't mean the way I interpret it. Regarding syslog I've always only managed to see log from the last boot, not before that, as in not what's logged during the crash. Can I make it persistent somehow?

I've had a lot of instability issues with my server, where the only fix is physical forced reboot. It seems to mostly been when writing, or heavy disk load, but seemingly not always. I have not at all figured out what is wrong with it. The parity checks have always come out fine. But when I installed scrutiny to check the S.M.A.R.T status of the disks it shows the parity disk has 36% Reallocated Sectors Count. "Count of reallocated sectors. The raw value represents a count of the bad sectors that have been found and remapped. Thus, the higher the attribute value, the more sectors the drive has had to reallocate. This value is primarily used as a metric of the life expectancy of the drive; a drive which has had any reallocations at all is significantly more likely to fail in the immediate months" It seems obvious I need to replace the parity drive, and will do so. But what I'm more curious about is if this can be the reason for the instability issue? When I write a lot to the disk, unraid write it to the disk and to the parity disk, the parity disk get to a bad sector and have to remap it, and then another one, and then another one simultaneously, and somewhere this crashes unraid? scrutiny also semi-crashed unraid, the gui or cli barely worked at all, managed to open 1 page in 10 minutes, and run one show command in the same period but failed to run any executive command (like turning off the scrutiny docker), while all dockers, scrutiny included, was working fine, so might be something messed up with a disk's S.M.A.R.T and unraids ability to handle this messed-up-ness. I had to give up and physically reboot and unraid was flowing fine again with scrutiny turned off.

Where is the non-docker version equivalent of /usr/share/jellyfin/web/ located when you have it as a docker on unraid?

That output was exactly what made me think you'd log into the console (and the fact that I for some reason thought you were a responder in the thread). So thank you very much for the explanation. But where is the Sweet. Again, though you were another responder going another route. I tried a couple of times more. Log just empty. But then I changed trying from "ben" to "ben1" it suddenly worked. No clue why, I probably did something different I didn't register. Big thanks for your help and support!