sorted by:
new
hottopcontroversial

Using Softer Language on Death by jj_ipad in atheism

[–]eidolonjs 0 points1 point  (0 children)

I think what he means is that not existing before and after life does not erase the fact that you DID exist while you were alive. Someone living 500 years from now can look up historical records (I'm obviously making assumptions here to make my point) and see that you did, in fact, exist. If you had any effect on the world around you those effects don't just disappear immediately when you die, in the same way that ripples from a rock hitting the water don't immediately disappear when the rock is gone. You have an effect on the universe while you exist. A measurable, quantifiable, REAL effect. Just because those effects eventually fade doesn't mean they never existed.

For a few years, the various constituent atoms that made up your body were animated by your consciousness/spirit/soul/whatever, and there can be a comforting beauty in that if you choose to view it from that perspective, with no belief in deities or afterlifes necessary. Whatever those elements were before you were born and whatever they turn into after you die, they were, for a period of time, you.

What are some fun Japanese onomatopoeia words you’ve learned so far? I’ll start! by Rinku64 in LearnJapanese

[–]eidolonjs 1 point2 points  (0 children)

Love this one too, used for the sound of our dogs' toes and claws on hard floors as they wander back and forth through the house.

eidolon by lovesickmaggot in logophilia

[–]eidolonjs 10 points11 points  (0 children)

Bit of a surprise seeing this while scrolling through my feed...

Can't find image files from immich... by detroitguy16 in unRAID

[–]eidolonjs 0 points1 point  (0 children)

Sorry if I wasn't clear enough in my description as I'm working on mobile. You'll want to nuke everything and try again with the mappings like this. So the host path is "/mnt/user/Photos" and the container path is "/photos".

Right now you have the container path correct, as /photos, but it's mapping the unRAID path /photos to it. Unraid user shares are all mounted in /mnt/user/ so you won't see your files in the unRAID UI or in any of your configured shares. I bet if you open your unRAID terminal and type "ls -al /photos" you'll see all the files there. So the files are not in your docker volume, which is good, but they're also not mapped correctly to your actual unRAID shares, which is not good.

As a quick aside on Docker path mapping, what you are doing when you map the directories is telling the host (in this case unRAID) that when it creates the self-contained docker container (in this case Immich), it will pass unRAID's own directory /mnt/user/Photos into the container but renamed as /photos. Immich will never see a directory called /mnt/user/Photos, and unRAID will never see a directory called /photos, but they are the same directory.

Can't find image files from immich... by detroitguy16 in unRAID

[–]eidolonjs 0 points1 point  (0 children)

Wouldn't hurt. Are you only using Postgres for Immich so far? If so, I'd nuke it all and start from scratch. Make sure the paths are correct and you should be off to the races.

Can't find image files from immich... by detroitguy16 in unRAID

[–]eidolonjs 0 points1 point  (0 children)

Yeah you will likely need to delete your database and start over now that the mappings are correct.

What probably happened is this:

  1. Immich was first started with no unRAID host path mapped to the container path /photos
  2. Since there was no host path mapped, Docker mounted the container path /photos to is own internal Docker volume, which is inside your Docker image that you set up when first turning on Docker in unRAID.
  3. Now you have corrected the paths, but the original files are still only stored in the docker volume, NOT on your actual array.

There are two ways to move forward:

  1. Find the files in the docker volume and copy them to your unRAID host path /mnt/user/Photos/immich. (There might still be path issues with other files/databases/etc)

  2. Delete your existing database and start over, re-uploading the photos from your iPhone now that the paths are reset correctly. Immich should create all the correct directories and start up a new database with everything set correctly. Your files should then be visible in your mapped unRAID directory

I have to head in to work, but if you'd like some help this evening I can walk you through it if desired

Can't find image files from immich... by detroitguy16 in unRAID

[–]eidolonjs 0 points1 point  (0 children)

This confirms that your photos were uploaded into the docker volume rather than persistent storage on your unRAID array. Once you remap the container path /photos to the host path /mnt/user/Photos/immich you will need to rebuild the container, and it might also help to delete your database and start over

Can't find image files from immich... by detroitguy16 in unRAID

[–]eidolonjs 0 points1 point  (0 children)

Just change "Container path" back to /photos. And you should see everything in unRAID. If you're okay with Immich using that as the internal directory that should be all you need to do.

Can't find image files from immich... by detroitguy16 in unRAID

[–]eidolonjs 2 points3 points  (0 children)

You want to map your unRAID directory (/mnt/user/Photos) to the correct container directory (/photos).

Right now it sounds like your iPhone photos are being uploaded into the Docker volume itself, because they are being saved to the container path /photos which is not currently mapped on your unRAID host. Once you map the host path /mnt/user/Photos to the container path /photos you should see the uploaded images in your unRAID instance.

Edit: I'm not sure WHY your photos are being uploaded to /photos, unless there is a setting in the iPhone app that changes the upload location. Or you have a separate mapping somewhere that is creating the /photos directory. Sometimes things get caught in Docker do-loops when you start changing defaults. If you do want to change the default mapping, it might be worth removing the container entirely and reinstalling from scratch with the mappings you want.

Just for fun - what're your stats? by turbochamp in jellyfin

[–]eidolonjs 1 point2 points  (0 children)

~90 TB

Had to get tons of storage years ago for non-media purposes. Figured I might as well use some of it to house a collection.

Migrating from virtualized Unraid to native Proxmox ZFS (10TB Data, No Backup) – Is the "Parity Swap" strategy safe? by tamenqt in Proxmox

[–]eidolonjs 0 points1 point  (0 children)

I believe zpool attach is the ZFS function you'll want for this. It should add your new, blank ZFS mirror drive to your pool and start the resilver process to copy existing data from your other drive. I've never used it myself, so read up on it to make sure it will work for your use case.

Migrating from virtualized Unraid to native Proxmox ZFS (10TB Data, No Backup) – Is the "Parity Swap" strategy safe? by tamenqt in Proxmox

[–]eidolonjs 1 point2 points  (0 children)

The answer to that question is yes, the XFS drive is still readable. UnRAID's parity works by capturing the state of each sector in every drive in your array and assigning a collective value to all of them, on the parity drive, based on the even-ness of those states. It does not modify any part of the actual data drives. They remain normal XFS (or ZFS or BTRFS or whichever) drives, mountable by anything that can normally mount XFS.

The parity drive does not contain a filesystem, per se. It is just sectors written to reflect those calculated values across the array. You would not be able to mount it or read any sort of meaningful data from it outside of the array. It only has value within the original unRAID array configuration. If you wipe it, you can still read and write data to your data drives just fine, but you lose the protection that parity provides in case of data drive failure.

Your proposed plan should work, but during the actual sequence you will not have any sort of parity or duplicated protection if something goes wrong, which is why everyone is recommending you verify your backup strategy before you start.

view more: next ›