You just dumped a full memory card onto your desktop
You finished a weekend shoot. Your camera card holds three thousand files. You plug it into your Fedora laptop, copy everything to ~/Pictures/2024-08-15, and now you need a way to browse, tag, and edit them without drowning in a flat directory tree. You need a photo manager. Fedora provides two mature options: Shotwell and digiKam. Both work well. Both handle metadata differently. Picking the wrong workflow now means migrating a database later.
What actually happens when you import photos
Photo managers do not just look at files. They build a local database. Every time you point the application at a folder, it scans the directory, reads EXIF and XMP metadata, generates thumbnails, and writes everything to a SQLite file. The original files stay exactly where you put them. The database is just a map. If you move files outside the application, the map breaks.
Think of it like a library catalog. The books sit on shelves. The catalog tells you where they are. If you rearrange the shelves without updating the catalog, the librarian cannot find anything. Photo managers follow the same rule. They track paths, not just filenames. They cache thumbnails to avoid decoding heavy RAW files on every scroll. They store tags and ratings in the database, and optionally write them back to the file metadata. Understanding this separation between the catalog and the actual files prevents half the headaches users encounter.
Fedora stores application data in ~/.local/share/ by default. Shotwell keeps its database at ~/.local/share/shotwell/data.db. digiKam uses ~/.local/share/digikam/. These paths are user-writable and isolated from system directories. Never edit files in /usr/lib/ or /usr/share/. Those ship with the package and get overwritten on updates. Your configuration and database live in your home directory. Trust that separation.
Setting up your library and import workflow
Start with the package manager. Fedora provides both applications as native RPMs. Native packages integrate better with the desktop environment, handle MIME types correctly, and share libraries with the system. Flatpak versions exist, but they sandbox file access and require manual permission grants for every new folder. Stick to the RPM unless you specifically need sandboxing.
Here is how to install Shotwell from the terminal.
sudo dnf install shotwell
# --refresh forces a metadata check before resolving dependencies
# ensures you get the latest repository state
# installs the package and all required libraries
Run the same command with digikam if you prefer that application. Once installed, launch it from your system menu. The first screen asks you to choose a library location. Point it at your main photo directory. Do not point it at your entire home folder. The application will scan every subdirectory, which wastes time and creates database entries for screenshots, wallpapers, and temporary files.
The import dialog offers two distinct actions. "Add Folder" creates a reference to an existing directory. The files stay where they are. "Import" copies files into the application's managed directory and creates a date-based subfolder structure. Use "Add Folder" when your files are already organized and you only need a catalog. Use "Import" when you are pulling from a camera card and want the application to handle the folder structure automatically.
Here is how to verify the import path configuration before you commit to a large batch.
ls -ld ~/Pictures/2024-08-15
# checks directory permissions and ownership
# ensures the application can read all files
# confirms the path matches what you selected in the GUI
If the permissions show drwx------ and your user is not the owner, the application will fail to read the files. Fix ownership with chown before importing. The application cannot bypass standard Linux permissions.
Verify the database and thumbnail cache
After the first import, check that the database grew and the thumbnail cache populated. The cache stores small JPEG previews so the application does not decode heavy RAW files every time you scroll. A missing cache causes lag and high CPU usage during navigation.
Here is how to inspect the database and cache sizes.
du -sh ~/.local/share/shotwell/
# shows total disk usage for the application data
# includes the SQLite database and thumbnail cache
# helps you confirm the import actually wrote data
A fresh library with a few hundred photos typically shows a database under fifty megabytes and a cache under two hundred megabytes. If the database is zero bytes, the application failed to write. Check your disk space and home directory permissions. If the cache is missing, the application will regenerate it on next launch, but it will take time. Let it run in the background. Do not force-quit during cache generation. SQLite locks the database file while writing. Killing the process mid-write corrupts the file.
You can also verify that metadata is being read correctly. Open a known photo with embedded EXIF data. Check the details panel. If the camera model, lens, and exposure time appear, the metadata parser is working. If the fields are blank, the file might use a non-standard format or the metadata was stripped during transfer. The application falls back to filename parsing when EXIF is missing. That fallback is less reliable. Keep your original files intact.
Common pitfalls and broken imports
The most common failure is a broken symlink or moved directory. You import a folder, then move it to an external drive. The application shows missing files. The database still points to the old path. You cannot fix this by editing the database directly. SQLite files are binary and fragile. Use the application's built-in "Relocate" or "Find Missing Files" feature. Point it to the new location. The application updates the internal paths and rebuilds the affected thumbnails.
Another frequent issue is permission denial on external drives. Fedora mounts removable media with uid and gid matching your user, but some filesystems like exFAT or NTFS apply restrictive default masks. If you see Permission denied in the import dialog, check the mount options. Add uid=1000,gid=1000 to your /etc/fstab entry or use the GUI mount dialog to set ownership. The application cannot read files it is not allowed to touch.
Here is what a typical SQLite lock error looks like when two instances try to write simultaneously.
Error: database is locked
This happens when you run the application from the terminal while the GUI is already open, or when a background indexer crashes. Close all instances. Wait ten seconds. Restart the application. The lock file in the temporary directory clears automatically. Do not delete the database file to fix this. You will lose your entire catalog.
Metadata corruption is rarer but more painful. If you see garbled text in the details panel or the application crashes when opening a specific file, that file likely has truncated EXIF or XMP blocks. Isolate the file. Test it with a standard image viewer. If the viewer also fails, the file is damaged. If the viewer works, the photo manager's parser hit an edge case. Report the bug with the file attached. Fedora tracks these upstream.
Reboot before you debug. Half the time the symptom is gone.
Shotwell versus digiKam
Use Shotwell when you want a lightweight catalog that handles basic tagging, simple cropping, and quick exports to social media. Use digiKam when you need advanced metadata editing, batch renaming, RAW development, and support for thousands of albums. Use Shotwell when your library stays under fifty thousand files and you rarely touch EXIF fields. Use digiKam when you shoot professional workflows, manage sidecar files, or need precise color management. Use Shotwell when you prefer a single-window interface that opens fast. Use digiKam when you want a multi-panel workspace with dedicated metadata, map, and face-recognition modules. Stay on the upstream Workstation defaults if you only deviate from the base packages occasionally.