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.