Spksrc: Transmission Updates Set Complete/Incomplete Folders No-Access

[Haravikk]

Setup

_Package Name:_ transmission
_Package Version:_ 2.94-16

_NAS Model:_ DS212j
_NAS Architecture:_ ARMv7
_DSM version:_ 6.1.6-15266

Expected behavior

All Transmission folders should remain readable by Transmission following update.

Actual behavior

Transmission's complete and incomplete folders are both set to no-access, like so:

d---------  19 sc-transmission transmission 65536 May 31 13:04 .complete
d---------   5 sc-transmission transmission 45056 May 30 17:29 .incomplete

Requiring them to be chmod'ed back to 750 (or 755 for access to all). It's as if they're effectively being chmod 000'd, but I haven't been able to figure out why, hopefully someone more familiar with the upgrade script's handling of permissions can see what's going on.

Steps to reproduce

_1._ Update Transmission

Notes

To clarify, I use .complete and .incomplete for managing Transmission's downloads because I also use an on complete script to link downloads into other directories, which I find easier to work with. I don't think this affected Transmission though, as they're just normal directories for it to download or move completed files into.

The issue is that permissions seem to be getting screwed up, perhaps a umask isn't being set correctly? I couldn't find anything obvious with a quick look.

[ymartin59]

• Have you upgraded from DSM 5 to DSM 6?
• Was "transmission" already installed before upgrade ?
• Where are these two folders located ?
  To notice, new "transmission" package expects them to be in "Share Folders" with ACL support.

[Haravikk]

I upgraded from 5 to 6 quite some time ago. I forgot to add that this issue is new since the change to the packaging format for Transmission, two or three (four?) versions ago, I've had this same problem each time but forgotten to report it (or just thought I'd wait and see if it happened again).

The folders in question are stored on a dedicated "Downloads" shared folder, I haven't converted it to Windows ACL, is that what you mean? I'm not sure why that should be relevant, nor why it should explain why permissions are being wiped out entirely; I don't use SMB or any other feature that should require a Windows ACL.

[ymartin59]

Thanks for details. Package framework now expects ACLs to be enabled, as it is defaults on DSM 6 and allow to implement file permissions and access segregation. Please read https://github.com/SynoCommunity/spksrc/wiki/Permission-Management for details and enable ACL on your shared folder. It is the "simplest way".

We tried to handle non-ACL shared folder created before DSM 5, but probably test implemented in script does not work as expected or does not support any situation because we lack systems to validate code:
https://github.com/SynoCommunity/spksrc/blob/master/mk/spksrc.service.installer#L150

If you agree to debug and propose a better support, do not hesitate to submit a PR... but it is not a priority for us, as any recent system has ACL enabled, and it is quite fast and easy to enable it on upgraded system like your.

[BenjV]

@ymartin59
Maybe it would be wise to add some tekst to the wiki explaining that the conversion of old shares to "Windows ACL's" supported shares is mandatory for using SynoCommunity packages.

I have seen this questioning of why to convert the share to ACL support already many times, because people think they have nothing to do with windows ACL's so why bother.
Synology made the unwise decision to name it Windows ACL but it has of course nothing to do with ACL's created by a windows PC(or something like that)
It is ACL's, just like windows use them.

[ymartin59]

@BenjV I added notice about ACL https://github.com/SynoCommunity/spksrc/wiki/Permission-Management#troubleshooting. Is that OK/enough?
@Haravikk I close that issue... Re-open if you are in troubles after enabling ACL support on Shared Folders.

[Haravikk]

Sorry, forgot to update again; I tried to figure out what was going wrong but whatever it is seems to be to do with the syno acl commands, as far as I can tell the update script isn't doing anything wrong, yet the command is wiping out the permissions for the folders on my linux type shares.

Anyway, I couldn't find a good alternative so I've just converted to "Windows" ACL which seems fine; why Synology didn't make it clear that I should have done this sooner is beyond me. Hopefully that resolves any future update issues.

[BenjV]

Synology did make it clear and so did the wiki of the SynoCommunity.
You just didn't pay attention and thought you knew how thing are functioning.
No permission is wiped out, just not used anymore by the new spksrc packages.

ACL's are a finer grade of permissions which is available besides the very course linux permission system.
Synology introduced that in DSM 5, but as long as you do not use it, it didn't do any harm not to convert your shares to support ACL's.
For very technical reasons it was necessary to use ACL's for the new spkrsc and all package from the SynoCommunity that write data to shares needs ACL support on that share.

DSM itself uses both system, but when ACL's are supported on a share you also get more options in DSM on the permission level.

[Haravikk]

What's with the attitude?

Synology absolutely did not make it clear; when I upgraded from DSM 5 to 6, I saw no notification or suggestion that I should convert to Windows ACLs, otherwise I would have done so. Indeed, had they just upgraded to them automatically I wouldn't even have noticed. Instead they made the conscious decision to leave existing systems on Linux permissions, which has led to my issue. There were no alerts or reminders to upgrade, and the option to do so is in a menu I have no reason to regularly access; maybe you constantly check the actions menu of your shared folder control panel for new options, but I can guarantee that 99.9% of users will not, and won't even use the shared folders control panel except when they need to add a new one.

And yes, permissions were wiped out; that was literally the entire issue I was reporting, which you don't appear to have paid attention to. Updating Transmission rendered my Transmission related folders inaccessible (both to Transmission and others), requiring me to restore access every time, hence why I reported it, otherwise I wouldn't have had any issue to begin with.

[BenjV]

What attitude? Yours?
Are you offended by the fact that you choose to ignore presented information by people how are trying to help?

And you don't understand the issue I am afraid.
Those permissions are still there but the package is changed and uses ACL's instead and so ACL support of the shares is needed.
That was clearly stated when you upgraded the package and also pointed out by both @ymartin59 and myself multiply times in this topic and you still ignored it.

Also Synology has stated information about ACL support on shares in the release notes of DSM 5.0, in the user manual, in the help and on the knowledge center of their website so clearly, you ignored that too.

And if you had red the warning in the wizard about the possible side effects of converting shares to ACL supported shares, you should have known that an automatic conversing to ACL supported share by Synology is not a good idea.

To be honest, the problem is the attitude of people who are getting a wonderful set of packages for free, created by the hard work of other people and then don't bother to put a little effort of just reading te information but complain about a tone of voice when that fact is pointed out to them.

[Haravikk]

Are you offended by the fact that you choose to ignore presented information by people how are trying to help?

No, because that's not what I said at all; I was criticising the Synology upgrade process from DSM 5 to 6, which didn't make it at all clear that Windows ACL is now the preferred (and default) method and left my system on the older Linux permissions setup while giving me no idea I might need or want to change it.

That was clearly stated when you upgraded the package and also pointed out by both @ymartin59 and myself multiply times in this topic and you still ignored it.

On package upgrade no it did not, recent updates have only referred to packaging changes, and that the update will attempt to set the correct permissions.

And I did not ignore those pointing out that I should convert to ACL; I literally announced that I had chosen to do so when you started accusing me of things. I also described how I initially tried to find a fix for the fallback command wiping out Linux permissions in an effort to help, but could not.

Also Synology has stated information about ACL support on shares in the release notes of DSM 5.0, in the user manual, in the help and on the knowledge center of their website so clearly, you ignored that too.

Ignored something that I would have to go out of my way to find, and was not told I should go out of my way to find? Ah yes, of course, somehow that's my fault rather than the update process that should either have upgraded something that requires upgrading, or at least informed me of this so I could do it manually.

To be honest, the problem is the attitude of people who are getting a wonderful set of packages for free, created by the hard work of other people and then don't bother to put a little effort of just reading te information but complain about a tone of voice when that fact is pointed out to them.

I have not complained about the packages, or syno-community; in fact martin59's responses have been very helpful. My only complaint is that the DSM 5 to 6 upgrade has left systems in a state, like mine was, where issues like this can occur.

Regardless, I reported an issue in good faith, ymartin59 was extremely helpful, the problem is now resolved.

I have no further interest in you, your attitude problem, or your apparently consistent inability to read what I actually said before you explode into a torrent of insulting accusations.

[rcontisplk]

I found a fix in my case, so feel free to read on (for the others out there will will have broken permissions and no easily google-able way of fixing it)

3rd or so time over perhaps 8 years that an update has totally broken Transmission permissions in a way that's utterly impenetrable to the average unix guy. For people who work on Synology packages every day, perhaps it's "obvious" that these changes are being made in DSM. For most end users it's no more intuitive than saying your toaster stopped working because your mains changed from 110v to 220v over the weekend, and you should have checked the utility company website more often.

I'll note that none of the other packages I use on my Synology have broken in unexpected ways across DSM versions or package updates, but I'm a mere casual user.

The fix in my case was to simply search for "ACL" in the Syno UI, select my folder, and apply windows file permissions recursively. I have no idea what headaches Windows file permissions will bring in the future, but at least it means I only spent 30 minutes solving an issue I didn't have when I woke up this morning.

Hope this helps others in a way that arguing does not.