Can't write to a file in mounted Samba share in Fedora Silverblue 40, but can in Fedora Workstation 39 and Debian 12

I created a Samba server on a Raspberry Pi, and I have no trouble accessing and using the server with GNOME’s Files/Nautilus in Fedora Workstation 39 live and Debian 12.

But in Fedora Silverblue 40, I can create, delete and rename files, but I cannot write to them.

My UID and GID is 1000/1000 on all systems.

Here is a sample log line from when the save fails in Silverblue 40:

Jun 07 13:50:50 hp-envy-silverblue gnome-text-edit[5142]: Failed to save document: Error opening file “/run/user/1000/doc/6bf18bce/text”: Operation not supported

I’m thinking this must be something in Silverblue, since I don’t have a problem with the Workstation live image or Debian.

Plus it’s only writing to files – and I CAN write to files on the Samba server on the non-Silverblue systems.

This is what I’ve added to /etc/samba/smb.conf on the server:

[homestead]
path = /media/usb/samba/
browseable = yes
writeable = yes
only guest = no
create mask = 0777
directory mask = 0777
public = yes
guest ok = yes

Remember, two other Linux systems on the same local network have no problem with this Samba server. It’s just the Silverblue system that can’t write to a file.

Any ideas?

Did you have a look at the change set from F40?

While I had a quick look, I saw openssl 1.1 and pyton v.3.7 retirement This apps have been available till F39.

Also move /var/run selinux-policy entries to /run # tha’t is my guess for the error.
Some environmental variable still pointing to the old place for an older app?

I just confirmed that I CAN write to a file on my Samba share from Files/Nautilus in Fedora Workstation 40. I also succeeded with CentOS Stream 9.

That means this problem is confined to Fedora Silverblue.

I don’t know which package to file a bug against.

Is there a simlnk to /var for /media ? Silverblue’s root filesystem is read only.
Technical Information :: Fedora Docs >> File system Layout

Please check with ls -al / to see if there is a simlink.

The Samba server is not on Silverblue. It’s on a Raspberry Pi running RPi OS.

The problem is with Silverblue as a client for the Samba share.

1 Like

Ok, sorry.

Above I asked you to check in Silverblue and not on the Workstation Legacy!

This sounds quite exactly what you have … problem with your userspace:

:link: Move /var/run selinux-policy entries to /run

Actual path for system runtime files moved from /var/run to /run some 10 years ago [1], but the policy has been managed since then in a way that keeps the old entries and have updates still with the incorrect path while the real path is handled by file equivalency feature. This can confuse sysadmins not to be sure which path should be actually used and can also effect in userspace tools not working properly [2].

After a lot of testing, I learned some things, and I think I can mark this as a solution.

It’s not that the Samba share is or isn’t working in Fedora Silverblue, or any other Unix/Linux system. Samba is working fine. I was able to mount the share via Files/Nautilus in Debian and Fedora Silverblue, and in Thunar (and Gigolo) with the gvfs-smb package in OpenBSD.

The problem has been with apps I am using to work with the files on the Samba share. Some work, others do not.

And the issue is with the gvfs filesystem that is used to mount the Samba shares. The issues are the same when an sftp site is mounted via gvfs in Nautilus/Files.

When I discovered the same issues in Nautilus/Files with sftp, I knew my problem had nothing to do with Samba, per se.

It was gvfs – specifically the apps that can and can’t work with a gvfs-mounted filesystem.

What threw me was that in Debian 12, I was using a text editor (Gedit) that works well with gvfs, and In Fedora, my editor (GNOME Text Editor) does not work terribly well in that environment.

So I did a bunch of testing across Debian 12 and Fedora Silverblue 40 (with GNOME) and OpenBSD 7.5 (with Xfce).

It all depends on which applications you are using to read and write to files in a gvfs filesystem.

Here’s what I learned:

Apps that work with GVFS filesystems:

  • LibreOffice Writer (I haven’t tested other programs in the office suite, but this one is a champ)
  • Gedit (Used to be my go-to text editor … might return to the throne)
  • Emacs (GUI version via Flatpak. The first save of a file throws a chmod error, but it’s smooth after that)
  • Kate
  • Kwrite (Great showing from the KDE apps)
  • Neovim (file opens in the terminal app with the GNOME file-open dialog. I’m surprised this works where Vim does not)

Apps that read only and can’t write:

  • GNOME Text Editor
  • Vim (Flatpak in terminal)

Apps that don’t work at all:

  • Geany
  • GVim

Apps that read and write, but not seamlessly

  • Mousepad (tested in OpenBSD, a dialog says the file wasn’t written, but it actually is. The dialog is annoying)

I still need to do some more testing, because I didn’t have problems reading and writing the files in Fedora Workstation 39 and 40, and I used the default text editor, not noticing whether it was Gedit or GNOME Text Editor. Maybe things are “easier” in Workstation. That’s another test for another day. OK, maybe later today …